QT App crashes when QMessageBox is called from another class.

[ademmler]

I want to call a message box - from another class than the main class. I use:

QMessageBox::critical(NULL, tr("Debug"), tr("I am here for debugging ..."));

What I get is:
020-09-25 07:59:09.266 MyApp[2357:45394] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!

What can I do? Thx to all helpers

[ademmler]

@jsulm thx for your idea. The SDK is under NDA - hence I can't pass it here.

I use "Qt::BlockingQueuedConnection" in the connect at the GUI-Event.
This works perfectly in this use case.

[jsulm]

@ademmler Do you call QMessageBox::critical in another thread than UI thread?

[ademmler]

@jsulm Yes exactly - this is what I need to do.

[JonB]

@ademmler
Well unfortunately @jsulm asked you that because you are not allowed to do that. You can only do Qt UI operations from the main UI thread. If you have another thread you must send a signal which your UI thread picks up (queued connection) and displays the message box on behalf of the other thread.

[ademmler]

@JonB thx for your comment

1. We had the discussion about Signals/Slots already within another thread. And yes I already use them. But in this case the second threads need to wait/pause until the user
   clicked the "OK" on the Message box. How can I achieve this then?

2. I found this solution - but I don't know how to get the right object for "parent()" ....
   A better way than passing nullptr is to use the qobject tree you are already using (assuming that the parent of the NetworkManager instance is a QWidget; adjust the number of parents according to whatever your qobject tree looks like)

QMessageBox::critical(qobject_cast<QWidget *> (parent()), "Title", "Message");

Regards Alex

(This is from this tread: https://stackoverflow.com/questions/15503000/how-to-call-qmessagebox-static-api-outside-of-a-qwidget-sub-class)

[Christian Ehrlicher]

I really wonder how often we have to tell you: no you must not call a gui operation outside the main gui thread.
If you need to wait for input use signals/slots to execute the next slot after the button was pressed in the main gui thread.

[ademmler]

@Christian-Ehrlicher

As far as I understood signals/slots is asynchronous - not procedural.
How can I wait in the second thread for this signal than?

In my case the second process has to open a connection to an measurement device.
This requires to be calibrated - for it needs:

1. Init connection to device and set this up - this thread and connection stays open than!
2. User has to be asked to place the device on its calibration tile and click OK when ready.
3. The device gets calibrated - connection stays still open!
4. Send User feedback to place device on monitor - click OK when ready!
5. Run Measurement loop ...

As you see - the second thread needs to be paused - waiting for the users feedback.
What would be here the the better solution:
BlockingQueuedConnection ?
Using QSignalSpy() ?

[jsulm]

@ademmler said in QT App crashes when QMessageBox is called from another class.:

What would be here the the better solution

Use a thread with Qt event loop

[ademmler]

@jsulm said in QT App crashes when QMessageBox is called from another class.:

Qt event loop

Thx for the hint, but this answer does not explain to me what you suggest and if you understood the core of my problem. Most of the Qt examples does not cover the complexity of operating "measurement devices" with a given vendor SDK - where you can't inject your own code. Can you give more details about your solution?

[jsulm]

@ademmler said in QT App crashes when QMessageBox is called from another class.:

Can you give more details about your solution?

You do it as usual in Qt: trigger an action, when it is done you emit a signal, slot connected to this signal is then executed (this slot can be in another thread). I can't explain it in more detail for your use case as I do not have all the details about this SDK and how it works.

[ademmler]

@jsulm thx for your idea. The SDK is under NDA - hence I can't pass it here.

I use "Qt::BlockingQueuedConnection" in the connect at the GUI-Event.
This works perfectly in this use case.