Slow responding UI in 3.3

[abeham]

It takes a relatively long time for e.g. a ValueParameterView hosting an OperatorView to show and become available for user input. The controls stay disabled after showing up and remain so for a noticeable period.

[abeham]

One reason may be that there are a number of statements that disable GroupBoxes and Panels that contain other controls. Sometimes these statements occur before e.g. setting the Content of a ViewHost to null. The call to disable a control however cascades to all child controls and thus disables all controls in the ViewHost which are then deleted anyway.

This seems to be only one reason however.

[abeham]

patch against r2866 that fixes some of the UI lags

[abeham]

I added a patch that fixes some of the problems with the UI. Specifically:

• I removed several of the .Enabled = false / .Enabled = true statements. I assume it does not matter when a group box is enabled when the content is set to null.
• The SelectedIndexChanged event of ListView fires multiple times, as it first deselects all items before selecting again. I added MouseUp and KeyUp events instead of SelectedIndexChanged that load the respective content in ItemCollectionView. This workaround was one described in the user comments of the MSDN doc.
• NamedItemView the call to set the ReadOnly property to false has been removed in the Content == null branch. I assume that if it's not enabled anyway it doesn't matter if it's ReadOnly or not.
• ParameterizedNamedItemView call to enable or disable the !parameterCollectionView has been removed. Id did not add anything, except maybe causing troubles with the UI updates.
• Several changes to ViewHost have been made:
  • Throwing an ArgumentException was removed in the setter of ViewType. But in any case it fits better here than in UpdateView.
  • A check was added if the ViewType property was really changed or same to what it was before. The reason is that the forms designer creates ViewType = null statements that can be ignored when ViewType was already null (after creating a new instance of ViewHost just a few lines before)
  • The initialize method was shrunken considerably. There was some code duplication between Initialize and UpdateView (disposing the controls for example). Some of the code has moved to UpdateView.
  • In UpdateView the control is removed before disposing. This didn't make things better, but seems cleaner. Calling Dispose on a control would also remove it from its parent container.
  • The ArgumentException has been disabled. I think it's not a good idea to throw an argument exception here. But that's preference. In any case it should probably be an InvalidOperationException instead.
  • Again Enable and Visible changes of the !viewPanel have been removed

[swagner]

Added some of the suggested improvements in r2870. UI reaction times are significantly better now. Thanks abeham.

[abeham]

I looked into the issue of having slow disable updates when starting an algorithm. Unfortunately, I couldn't find anything in our code. I assume that windows forms is not very effective at handling the recursive disable/enable.

There is another solution proposed ​here, which works, and which I have implemented in AlgorithmView to demonstrate the effect. I liked the solution of putting the code into extension methods of Control. Probably the extension method class should go into a new project such as HeuristicLab.Common.Views. For now, I wanted to keep the changes simple to review this solution.

See changeset in r3149

[swagner]

Thanks abeham. This is a great solution.

I suggest that we move the extension methods of Control into HeuristicLab.MainForm.WindowsForms.

[swagner]

Moved extension methods of Control from HeuristicLab.Core.Views to HeuristicLab.MainForm.WindowsForms and suspended/resumed repainting in some controls to improve UI response times in r3177.

[mkommend]

added Suspend- and ResumeRepaint calls in ViewHost and ViewHostPanel r3720

[swagner]

Milestone Iteration 4 deleted

[swagner]

Milestone Current deleted