OMEdit is not responding since r24043 when loading graphical models

[Jan Kokert]

After updating my old nightly build (r23603) to the newest version (r25481) I face a really weird problem opening model files:

After double clicking in the library tree the model is displayed in the diagram view.
But the horizontal scroll bar is shown, hidden and shown again and the model is automatically zooming in and out a bit several times, all in less then half a second.
After this, OMEdit hangs completely (Windows says: OMEdit.exe is not responding) and I need to stop omc.exe and OMEdit.exe via task manager.

I narrowed the problem down:
1.) I only observe this problem on one specific machine, which has seen in fact about 20 reinstalls of OM. With other machines its fine.
2.) I deleted all temp files, the settings.ini, did a windows registry clean and thus tried to do a clean reinstall but the problem persists on that machine.
3.) By bisection I figured out, that the error occurs from r24030 (is working) to r24043 (is not working).
4.) The problem occurs, when the Messages Browser is visible and thus reduces the available vertical space.
5.) The problem occurs for my own models and also for graphical Modelica examples.
6.) I guess it is related to r24036 (from 01/14/15)

It would by great, if one could fix that, so I can run the latest nightly build on my main machine. :-)
Reverting r24036 would be my first try.

Best Regards

[massimo ceraolo]

This might be related with #3248.
In that ticket adeas31 said:

There is no code where window size is changed. The size of MainWindow is only set in MainWindow constructor i.e before even OMEdit is made visible to user for the first time.

Now I remember that the OMEdit compiler Qt, of which I have some experience, manages itself window sizes by means of its sizePolicy, minimumSize, and maximumSize and other similar proprieties. In case "layouts" are used", layout interferes with widget sizes.
In ticket #3248 I had issues on low screen resolutions. Maybe there is some action from qt resizing windows in this case and in case of #3248 as well.

[Adeel Asghar]

The problem seems to be with the fitInView call. According to Qt docs here ​http://doc.qt.io/qt-4.8/qgraphicsview.html#fitInView,

It's common to call fitInView() from inside a reimplementation of resizeEvent(), to ensure that the whole scene, or parts of the scene, scales automatically to fit the new size of the viewport as the view is resized. Note though, that calling fitInView() from inside resizeEvent() can lead to unwanted resize recursion, if the new transformation toggles the automatic state of the scrollbars. You can toggle the scrollbar policies to always on or always off to prevent this (see horizontalScrollBarPolicy() and verticalScrollBarPolicy()).

The default behavior of scroll bars is Qt::ScrollBarAsNeeded. So depending on the size scroll bars might appear and disappear which might lead us to recursive resize events.

In r25515 I set the scroll bars policy to Qt::ScrollBarAlwaysOn. I hope this will fix the issue.

[Jan Kokert]

Thank you for this very fast response! This unwanted resize recursion stuff sounds totally reasonable. I will try it out tomorrow afternoon with the latest nightly built.

BR
Jan

[Jan Kokert]

I was so keen and I tried it directly in the morning and bingo - it's working now. Perfect. You can close the ticket :)