My Qt application's main window is a normal QMainWindow
subclass. In that window I have a few buttons; each has its clicked
signal connected its own slot, and each slot creates a different QDialog
like so:
void onButtonA_clicked()
{
MyADialog* dialog = new MyADialog(this);
dialog->exec();
delete dialog;
}
I've been reading this article: https://wiki.qt.io/Threads_Events_QObjects#Events_and_the_event_loop and the author says
you should never ever block the event loop
which got me concerned; exec
is a blocking function, so according to what he says there (his example with Worker::doWork
which does a lot of work and needs some time to complete) my code is blocking the event loop, but I have not noticed anything that would suggest this; on the contrary, the main window seems to behave normally, and there was no difference when I changed the code to use the show()
method.
Am I blocking the event loop? Should I use a different approach here?
QDialog::exec()
blocks the main event loop, yes. It doesn't block the UI though, as it opens a local event loop inside exec()
, which processes events while the dialog is open. That can be a source of nasty bugs: (Almost) anything can happen before exec()
returns, external events (timers, network, IPC, whatever) can call slots, cause other dialogs to appear, etc. Just the ways for the user to do unexpected things directly are usually limited, given the modal nature of most such dialogs.
One needs to be aware of the possible issue and not leave the application in an inconsistent state when calling exec()
, and not rely on things to be as they were afterwards.
Alternatively, call the non-blocking QDialog::open()
and connect to the finished()
signal.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With