Does calling QDialog::exec in a slot block the main event loop?

Question

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?

Allieallied

As far as I know, int QDialog::exec() doesn't block the Qt application, just the parent window and only if the dialog is window modal. – Inning

@Inning Well, it is a blocking function (in that it doesn't return until the QDialog is closed), which is why I'm unsure. – Allieallied

Answer 1

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.

Loft

A followup question - does the same situation apply when using a QMessageBox with exec()? How about a QMessageBox instantiated with the Static Functions API i.e. : int ret = QMessageBox::warning... – Sourpuss

@Sourpuss all above also applies there – Loft