QMessageBox::warning replacement that wont process the event loop

[stefanwoe]

@J-Hilk
i tried this here (of course a incomplete test):

QMessageBox msgBox(this);
msgBox.setText("My message");
msgBox.setStandardButtons(QMessageBox::Yes | QMessageBox::No);
msgBox.setDefaultButton(QMessageBox::Yes);
msgBox.setWindowModality(Qt::ApplicationModal);
msgBox.show();

show() now of course will not wait until the dialog is closed etc. How can i accomplish this? It seems like the correct way, but so far i dont get it.

[J.Hilk]

@stefanwoe
make msgBox persistent, for example as a class member, then it should at least show.

[stefanwoe]

@J-Hilk It shows - but i how can do i add a loop or the like to process the dialog until a button is pressed?

[J.Hilk]

@stefanwoe you can't that's why I wrote:

but, this will result in your having to refactor stuff, as the show() call does not "wait" inplace on the user input!

your code/ function block will have to end on the show() call of your message box, and than you "continue" in a slot/function connected to one of its signals, for example
https://doc.qt.io/qt-5/qdialog.html#finished

[stefanwoe]

@J-Hilk That i understand - but this will continue code execution after the msgBox.show() statement - as it wont block control flow. So the code after msgBox.show() will be executed while the dialog is shown. But what i want, is a replacement for QMessageBox::warning which blocks further execution while the dialog is shown.
How can that be done?

[J.Hilk]

@stefanwoe said in QMessageBox::warning replacement that wont process the event loop:

How can that be done?

it can't not without calls to processEvents() or additional QEventLoops

[mchinand]

This post is deleted!

[JonB]

@stefanwoe
As @J-Hilk says.
And since your earlier traceback showed

...
Qt6Cored.dll!QEventDispatcherWin32::processEvents({...}) Line 474	C++
Qt6Guid.dll!QWindowsGuiEventDispatcher::processEvents({...}) Line 72	C++
Qt6Cored.dll!QEventLoop::processEvents({...}) Line 140	C++
Qt6Cored.dll!QEventLoop::exec({...}) Line 232	C++

it seems to me likely/possible that you will be in the same state as you were originally.....

[stefanwoe]

I now tried:

QMessageBox msgBox(this);
msgBox.setText("My message");
msgBox.setStandardButtons(QMessageBox::Yes | QMessageBox::No);
msgBox.setDefaultButton(QMessageBox::Yes);
msgBox.setWindowModality(Qt::ApplicationModal);
msgBox.show();
QEventLoop eventLoop(&msgBox);
eventLoop.exec(QEventLoop::DialogExec);

Still the same problem.

Inspecting the call stack in the debugger i think the root problem lies in

Qt6Guid.dll!QGuiApplicationPrivate::processWindowSystemEvent(0x000001577107c8c0) 
Qt6Guid.dll!QWindowSystemInterface::sendWindowSystemEvents({...}) Line 1172	C++
Qt6Guid.dll!QWindowsGuiEventDispatcher::sendPostedEvents() Line 81	C++
Qt6Cored.dll!QEventDispatcherWin32::processEvents({...}) Line 474	C++
Qt6Guid.dll!QWindowsGuiEventDispatcher::processEvents({...}) Line 72	C++
Qt6Cored.dll!QEventLoop::processEvents({...}) Line 140	C++
Qt6Cored.dll!QEventLoop::exec({...}) Line 232	C++

I can not find any configurable way to - temporarily - skip this call chain, when using QEventLoop.

[JonB]

@stefanwoe
I don't think you can, that is my point. You need an event loop to deal with any dialog, and some event being processed is upsetting something in the system....
Really ISTM the original issue, whatever it is/causes it, ought be sorted out. Like a (reproducible) bug report. But that may take time for a resolution.....

[stefanwoe]

I found this SO discussion which states the same problem:
https://stackoverflow.com/questions/26502673/will-qmessagebox-block-the-running-of-the-whole-main-thread-in-qt

The solution here is:

This is why we have a policy in our company that forbids to use QMessageBox::question() (and similar) and to call exec() on dialogs in our applications. We are creating modal dialogs on the heap and use their signals instead.

Well - can anybody tell what that means? Would this work without a event loop?

[SGaist]

Hi,

It just means that they impose a single event loop throughout the whole application lifetime.

Basically, you should refactor your logic so that you do not depend on the fact that the event loop is processing events.

Can you explain how you implement your logic ?

[stefanwoe]

@SGaist As noted before - the problem only arises sporadically in not so common situations. I can not "refactor my logic" thanks for that hint. As the SO post shows i am not the only one who has that problem. And problems with event recursion are a common problem id say.

[stefanwoe]

@stefanwoe Let me give you a better example: A 3rd party Library we use throws a unexpected exception. We catch this exception and we want to display it (many users just send screenshots instead of logfiles). In some cases the library can not recover from the problem and/or it gets difficult to handle this before it ever had happened. In such a situation the dialog just should "Pause"/Halt the application and display appropriate information - but the application shall not execute any more. We may then i.e. create a Windows Dump file etc. for post mortem analysis before our program possibly will die.

[JonB]

@stefanwoe
As I understand it. Whether you use exec(), which will create its own event loop, or show(), which will will leave the main event loop running, either way Qt will process new events. And I believe you are saying you want to forbid this while the message box is showing(?).

Since I see you are Windows, have you considered maybe using a modal native Windows messagebox, which I am hoping would block the Qt event loop while displayed, would that satisfy you requirement?

[stefanwoe]

@JonB Yes, i consider writing a Native Dialog for Windows, and one for the Mac. But actually it would be fairly easy to add such a flag to i.e. exec() that forbids the current behavior.
And i still wonder how the approach in the linked Stackoverflow (above) answer would work. this seems to solve the problem.

[JonB]

@stefanwoe said in QMessageBox::warning replacement that wont process the event loop:

And i still wonder how the approach in the linked Stackoverflow (above) answer would work. this seems to solve the problem.

It does not seem to solve your issue at all to me. You want a message box to run without Qt processing an event loop and therefore dispatching other events. I say Qt does/can not do that. As @SGaist observed earlier:

It just means that they impose a single event loop throughout the whole application lifetime.

So they are just using the single main event loop even when the dialog is showing, instead of the dialog having its own event loop when you call exec(). I do not see any difference wrt your situation. That is my understanding.

[J.Hilk]

@stefanwoe said in QMessageBox::warning replacement that wont process the event loop:

And i still wonder how the approach in the linked Stackoverflow (above) answer would work. this seems to solve the problem.

Just like I suggested on the previous page!

In order to be able to click on any button or even to draw/show the dialog, the event loop has to be processed.

That is either done by the main event loop or by one QMessagebox is spawning or by one you yourself create. BUT event processing will be happening, if you wan't a responsive UI-window.

In your case you want only the main event loop to be spinning.

[stefanwoe]

In your case you want only the main event loop to be spinning.

How could that be done? Is there a example?

[J.Hilk]

@stefanwoe

#ifndef SOMECLASS_H
#define SOMECLASS_H

#include <QWidget>
#include <QMessageBox>


class SomeClass : public QWidget
{
    Q_OBJECT
public:
    explicit SomeClass(QWidget *parent = nullptr);

    void oldBlocking();

    void newNonBlocking();
signals:

private slots:
    void continuationOfnewNonBlocking();

private:
    bool someCondition() {return  rand() % 2;}

private:
    QMessageBox m_messageBox;
    QMetaObject::Connection m_lastConnect;
};

#endif // SOMECLASS_H

---

#include "someclass.h"

#include <QDebug>

SomeClass::SomeClass(QWidget *parent) : QWidget(parent)
{
    m_messageBox.setWindowModality(Qt::ApplicationModal);
}

void SomeClass::oldBlocking()
{
    if(!someCondition()) {
        QMessageBox::information(this, "Bla", "blubb");
    }
    
    qDebug() << "Do stuff as normal";
}

void SomeClass::newNonBlocking()
{
    if(!someCondition()) {
        m_messageBox.setText("blubb");
        m_lastConnect = connect(&m_messageBox, &QMessageBox::accepted, this, &SomeClass::continuationOfnewNonBlocking);
        m_messageBox.show();
    } else {
        continuationOfnewNonBlocking();
    }
}

void SomeClass::continuationOfnewNonBlocking()
{
    QObject::disconnect(m_lastConnect);
    qDebug() << "Do stuff as normal";
}