Consecutive progress dialogs causes application to lock up on macOS?

[Thuan_Firelight]

Hi all,

I was going to report this as a bug, but thought I checked with the forum first in case there is something I missed.

int Application::exec()
{
    QProgressDialog firstDialog("First Dialog", "Cancel", 0, 0);
    firstDialog.setMinimumDuration(500);
    QTimer::singleShot(5000, this, [&]()
    {
        qDebug() << "activeModalWidget" << qApp->activeModalWidget();
        firstDialog.done(QDialog::Accepted);
        QProgressDialog secondDialog("Second Dialog", "Cancel", 0, 0);
        secondDialog.setRange(0, 100);
        for(int i=0; i <= 100; i++)
        {
            secondDialog.setValue(i);
            QCoreApplication::processEvents(QEventLoop::AllEvents, 20);
        }
        qDebug() << "secondDialog.closed" << !secondDialog.isVisible() << "activeModalWidget" << qApp->activeModalWidget();
    });
    firstDialog.exec();
    qDebug() << "firstDialog.closed" << !firstDialog.isVisible() << "activeModalWidget" << qApp->activeModalWidget();
    return 0;
}

The above is a small sample of the code to reproduce the issue on macOS. Tested this using 5.4.1 and 5.12.3. It seems on macOS, after done() is called, the progress dialog is still hanging around for a bit longer (stepping through this code on Windows I can see the first progress dialog going away but on macOS it is still visible on screen).

Bring up the second progress dialog right after causes the firstDialog.exec() to get stuck and the program never finishes (i.e. "firstDialog.closed" will not be printed).

On Windows this runs fine, is this a known issue or should I report this as a bug? Only seem to happen when using QProgressDialog, I couldn't get it to happen if they are just regular QDialog.

[J.Hilk]

@Thuan_Firelight
You're not supposed to spin the event loop yourself, especially without and QApplication instance, you're bound to get undefined behavior.

processEvents

[Thuan_Firelight]

@J-Hilk said in Consecutive progress dialogs causes application to lock up on macOS?:

@Thuan_Firelight
You're not supposed to spin the event loop yourself, especially without and QApplication instance, you're bound to get undefined behavior.

processEvents

Thanks, my code example was overly distilled, in our production code we do have an QApplication instance and valid event loop running. You are right, though it seems calling processEvents setValue is no longer required. I might have remembered it incorrectly, but I thought that was how we were meant to use the progress dialog when not using the exec() version. Might be older Qt though.