# Changes between Version 202 and Version 203 of ReviewHeuristicLab3.3.0Application

Ignore:
Timestamp:
04/26/10 09:50:28 (12 years ago)
Comment:

--

### Legend:

Unmodified
 v202 === Priority: HIGHEST === * Adding a ValueParameter in a VariableCreator and selecting a generic type e.g. ItemList fails because no choice can be made on the generic type of the ItemList (ticket #42). * When the TSP importer is used after pausing the execution, the engine should be reset. === Priority: HIGH === * The flow chart is very nice, but sometimes arrows are a bit wild and going backwards which creates a not so nice strikethrough appearance. Would be good to have non-direct arrows as well. * swagner: In a discussion with maffenze it was decided to address this issue after the release of HeuristicLab 3.3.0. * Adding a ValueParameter in a VariableCreator and selecting a generic type e.g. ItemList fails because no choice can be made on the generic type of the ItemList (ticket #42). * The !OperatorGraphVisualization doesn't respect operator collections (e.g. SequentialSubScopesProcessor). * mkommend: This feature will rarely be used by a standard user and it will not be fixed right now. Although special shapes for MultipleCallOperators are planned. * In TypeSelector filter types that don't have a constructor (like currently PathTSPTour). * swagner: Generally all items should provide a parameterless constructor. I implemented one for PathTSPTour in r3139. * When the TSP importer is used after pausing the execution, the engine should be reset. * When there is an error in one of the item's constructors, the TypeSelector dialog (when pressing the "new" button) will open the first time, but stop listing items after encountering the item with the error. The second time the TypeSelector is shown through the "new" button, the optimizer crashes with an exception. * A !KeyNotFoundException is thrown in Values_ItemsAdded when a DataTableView is closed while it is updated. * TypeSelector view: When only one single type is possible (e.g. DoubleData), select that type and auto-close with OK. * In a discussion with maffenze it was decided to show the type selector dialog in every case as we fear that it might be irritating for a user, if the dialog is sometimes shown and sometimes not shown. * A problem should inject a variable that indicates its dimensionality (sometimes you want to set values depending on the dimension of the problem). * swagner: In a discussion with abeham it was decided that a problem dimension parameter is not really required. * Adding a new parameter through the GUI and choosing a ConstrainedValueParameter does not make sense as the set of valid values cannot be defined anywhere in the GUI. The parameter will never be able to take a value. Additionally, switching the view for this ConstrainedValueParameter to a ValueParameterView and setting a value there leads to an exception. The ValueParameterView should not be a view for the ConstrainedValueParameter. * Adding a new ValueParameter could create a default value if T is instantiable. For most !ValueParameters you will want to have a value upon creation.