Qt5 QDialog and exec()
-
I have a program that ran fine using Qt 4.8.4 but now doesn't work properly. I've created a subclass QDialog that I intend to use multiple times in order to process a set of images, one after another. The QDialog subclass let's me ask the user if the process worked correctly on the particular image before moving to the next. So I send some set up methods in the class and then use the exec() command to get the users response. I then set up the class with the next image and use the exec() command again and wait for a response. Note that I don't close the class, just load it up and exec(). In Qt 5, the class comes up the second time, but the interface is completely unresponsive. I hit the pause button in the debugger, and the debugger tells me that Qt is in the QDialog::exec() method and is stuck there.
Anyone know what I'm doing wrong or if this is a bug in Qt 5?
-
I should add that the QDialog subclass is sitting inside a QStackedWidget. So I make the dialog subclass the current widget in the stack just prior to calling exec().
-
I am not sure how you are using the exec command other than assuming you are checking the return value. It might be better to do this in the subclass of the dialog itself?
Example:
@
void TSubclassedDialog::closeEvent(
QCloseEvent *Event)
{
if(!this->IsImageAcceptibleToUser())
{
Event->accept();
return;
}Event->reject();
}
@ -
Yes, that is what I'm doing. I create the dialog subclass. Set some parameters inside the subclass. Then I exec() the subclass. In the subclass' form, I have an accept and reject button. On the accept button, I save the current settings and then call the accept() method. This returns to the exec() calling routine which checks the result. If its okay, I move on to the next image and that leads to another exec() on the subclass; otherwise, I stop the process and do not call exec() again.
-
Ok, I see what you are doing. It does seem odd that it doesn't work.
As a guess maybe there is an event that must be processed between calls to exec(). Maybe if you added 'qApp->processEvents();' in the loop this might help.
My suggestion wasn't exactly the way you are doing this by the way. If it is only an image that is changed you could update it by rejecting the closeEvent() call and loading the next image without returning from exec() until it is no longer acceptable. One advantage is that the dialog wouldn't flicker as it is destroyed then re-created. Just a thought.
Is there anything else between the exec() calls that might be causing the problem (saving settings perhaps?).
-
Wow, that suggestion got me thinking in the right direction. I added a process event call just before the exec() call, but that didn't work. I then thought maybe I would make the window disappear by forcing the stack widget to go to a different widget and then come back to the Dialog subclass, a sort of now you see it now you don't. That worked like a charm. So clearly there is something in a QDialog after the exec() runs that requires the window to disappear and then re-appear.