QMessageBox::warning replacement that wont process the event loop

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";
}

SGaist

Depending on the modality wanted, open makes it window modal.

JonB

@J-Hilk said in QMessageBox::warning replacement that wont process the event loop:

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

My understanding is that the OP says he wants/demands no Qt event loop to be running while his dialog is shown, that is the problem....

If you read his original report, for example, a window receives an "activate" event for some reason, and he does not want that or any other event to be processed....

J.Hilk

@JonB

@J.Hilk said

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.

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

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

How could that be done? Is there a example?

therefore my answer/example

JonB

@J-Hilk
If you say so! Certainly the OP should try what you have suggested :)

stefanwoe

@J-Hilk Thanks very much for your efforts!
Unfortunately this does not what i need. If i write

SomeClass testMessageBox(this);
testMessageBox.newNonBlocking();
nextStatement();

A Dialog window is shown but code keeps executing nextStatement(); etc. before i have a chance to press any button or even to read the text of the MessageBox as the it disappears when the object "testMessageBox" is destroyed as its scope is left. oldBlocking() behaves like the existing QMessageBox .

What i need is a call like

testMessageBox.execWithoutProcessingUnrelatedEvents();

This call should BLOCK (not nonBlock) execution of further code (it shall not cal nextStatement() as long as the MessageBox is shown) and it should only process events for its own window. From the StackOverflow post this seems possible - but i dont know how to do this.
The class you supplied does not do this.