Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QDialog widget - Resizing window and moving the window freezes my machine [workaround]
Basically, what is happening is that I have a qdialog widget that I compile with VS2012 using version 4.8.5. I also have a VS2010 compiled with 4.8.3.
What is happening is that whenever I try to resize the qdialog (VS2012 version) or move the window around, my windows machine freezes (the mouse can move but I can't click anything) until I press ctrl+tab to switch to a different open program. When I switch back, the qdialog is fine again as if nothing ever happened. Also, I put break points QDialog::resizeEvent() and that never gets called.
However, in the QDialog I have compiled with VS2010 and Qt version 4.8.3, things go about as they should. I also have it compiled for the mac using qt 4.8.5 and that is totally fine. QDialog::resizeEvent() gets hit as it should.
Note: I found this with VS2012 compiled with version 4.8.4 and tried to upgrade to 4.8.5 to see if it became fixed because the mac version I compiled with 4.8.5 worked.
Does anyone have any idea on why this is happening?
Turns out the issue has been there for a while now and is related to building with VS2012 on Windows 7.
Here's a link to the issue in case anyone ever gets the same problem. It contains a workaround:
Hi and welcome to devnet,
Can you also try with Qt 4.8.5 built with VS2010 ?
This might either be a regression in Qt or a problem with VS2012 (a quick check to "the bug report system":bugreports.qt-project.org/issues/ can also be a good idea)
Okay, I will try that. If it does end up having something to do with VS2012, should I make a bug report?
Sure you can
If you want a second opinion (also a good idea), don't hesitate to ask on the interest mailing list, you'll find Qt's developers/maintainers there, this forum is more user oriented.
Okay, I see. I did find a bug already listed for it. Hopefully, it'll be fixed someday. Apparently, its related to how Qt uses the windows multimedia timer. We managed to get around it by increasing the timer interval.
Great you found out !
Thanks for sharing your findings. Could you also update the thread's title to something like [workaround] so other forum users may know that a solution exists :)