PDA

View Full Version : Bug - Application Locks when user tries to move QDialog window



SKolaMunn
7th December 2010, 15:44
I am using QT 4.7.0 on a Windows 7 32bit PC, developing in MS Visual Studio 2008.

I have a QT application that opens a QDialog which operates as a video player. When playing the video (which uses a timer to update the QLabel displaying the current frame), if the user tries to move the window (by click and drag in the title bar), the whole application locks up. It unlocks when I press Ctrl-Alt-Delete to pull up the Windows Task Manager.

Is this a known bug? Is there a fix for it? If not, is there a way I can disable the user's ability to move the dialog during playback?

I appreciate any suggestions! Thanks!
~Susan

high_flyer
7th December 2010, 15:49
Is this a known bug?
Its probably a bug in your code, so I don't think its known.

Can you show the code that manages the video and the slot that reacts to your timer for the frames?

SKolaMunn
7th December 2010, 16:57
I thought it was a QT bug because I saw a similar (but not exact) problem posted by someone else (http://bugreports.qt.nokia.com/brows...mment-tabpanel). Anyways, here's some code snippets:

_pDisplayTimer = new QTimer(this);
_pDisplayTimer->setInterval(_frameSpeedMilisec);
connect(_pDisplayTimer, SIGNAL(timeout()), this, SLOT(displayNextFrame()));

The displayNextFrame function grabs a new frame from the video, performs some computations (not on the image itself, on other data), and draws on the video frame, then sets the editted video frame to the label's pixmap. Should I have some sort of call that checks if other signals have been detected or something? I didn't think there was a bug in the code because everything else works during playback (checking/unchecking display options updates frame, etc) and you can set it to play at double speed and it still plays (so I didn't think it was an issue with the displayNextFrame function taking too much time). But, I can definitely believe the problem is in my code! Thanks for your help.

UPDATE:

I fixed the problem! I added QApplication::processEvents() at the end of my slot. Thanks so much for the help, you lead me to the solution.

franz
7th December 2010, 19:32
You have be aware of the following: processEvents() starts a new event loop, which can lead to unpredictable behavior (http://labs.qt.nokia.com/2010/02/23/unpredictable-exec/). Ideally, you wouldn't have to call processEvents. So now that you know that your calculations block the application too much, you might want to consider investigating QtConcurrent for future improvements.

high_flyer
7th December 2010, 20:38
You have be aware of the following: processEvents() starts a new event loop
This is not true as far as I know, it only triggers event processing for the QApplication event loop.

franz
7th December 2010, 21:02
True. The effect however is practically the same. Let's restate that as: processEvents() will re-enter the event loop, which may cause unpredictable behavior.