does not return from exec()

explorer100

In non-modal mode - when a new dialog is invoked, the exec() of any other running dialog no longer returns with a value. Control of all other active dialogs goes to their respective Accept() and Reject() functions if specified and stops there. Basically only one exec() at a time. Is this the correct behaviour? and is there a way to circumvent this behaviour without going to modal mode?

jsulm

@explorer100 said in does not return from exec():

Basically only one exec() at a time. Is this the correct behaviour?

Yes, this is correct behavior. How would you invoke exec() more than once at the same time? exec() is blocking. Use show() instead of exec() if you don't want to have modal behavior.

explorer100

@jsulm thank you so much for the clarification. But this means, all (OK, Cancel, window close) processing will need to be handled in the dialog Accept() and Reject() functions. Not external to the dialog. Is this correct?

jsulm

@explorer100 said in does not return from exec():

But this means, all (OK, Cancel, window close) processing will need to be handled in the dialog Accept() and Reject() functions

Not sure what you mean here. It's the dialog itself handling OK/Cancel.
If you want to be notified that a dialog was closed connect a slot to https://doc.qt.io/qt-6/qdialog.html#finished

One correction to what I wrote before: there is also https://doc.qt.io/qt-6/qdialog.html#open instead of show()

explorer100

What I meant is the exec() returns values of 0,1,-1 and possibly others indicating if dialog accept/reject were selected by the user (through for example clicking OK button). Based on this return, processing can take place of the OK/Cancel outside of the dialog. But with non-modal it seems that approach cannot be done, and all OK/Cancel processing would need to be handled from within the dialog itself - in the Accept() Reject() functions of the dialog. Is this correct?

jsulm

@explorer100 said in does not return from exec():

with non-modal it seems that approach cannot be done

Of course it can be done. Did you check the link I gave you (https://doc.qt.io/qt-6/qdialog.html#finished)? This signal provides the result of the dialog as parameter. So, again: connect a slot to this signal and check the "result" parameter to react accordingly.

explorer100

Great.. thank you.. I will check it.

explorer100

Thank you very much.. works beautifully!

explorer100

I tried this method for a modal dialog .. (connecting the finished() and using show()), but the dialog did not show (actually shows up then immediately disappears).
Maybe a mistake on my side? or is that the expected behavior for a modal dialog?

Christian Ehrlicher

@explorer100 said in does not return from exec():

Maybe a mistake on my side?

I would guess it's a lack of c++ knowledge - what's the lifetime of the object?

explorer100

@Christian-Ehrlicher I'm not sure what you mean by "lifetime of the object".. you mean difference in time of before it shows up and after it disappears? its nano seconds.

SGaist

Hi,

The lifetime of an object correspond to where it's created until it's destroyed. Typically, in your case, you are likely creating your dialog on the stack in a function and that variable is thus destroyed when the end of the function is reached.

explorer100

@explorer100 ok great! yes you are right.. it is created in a function, not in the main program. that is why it disappeared. ok. so when it is in modal mode, with exec(), the function will remain.. makes sense. thanks,

explorer100

why some dialogs remain visible even after program terminates?

JonB

@explorer100 said in does not return from exec():

why some dialogs remain visible even after program terminates?

No dialog or window could remain visible if your program terminates. If you still see them that means your program has not terminated, even if you think it has. For example, just because your main window closes does not automatically mean your program has terminated. By default a Qt UI application closes when the last top-level window closes. If your windows all have that as an ancestor they will close too, and the application will exit. But if, say, you create a modeless, non-parented top-level window that will not close when the main window does, and the application will not close while that is still open.

explorer100

"But if, say, you create a modeless, non-parented top-level window that will not close when the main window does, and the application will not close while that is still open."

I think I have done exactly that. using:

if name == "main":

app = QApplication(sys.argv)
window = MainWindow()
window.show()
sys.exit(app.exec())

How else would you do it?

SGaist

By default, the application should quit after the last top level window is closed.
You can change that behaviour but it's an explicit thing you have to code.

JonB

@explorer100
If that code is all you have, and you do not change default quitOnLastWindowClosed to False, your application should fully exit when you close your window. Why don't you test just that program as it is with nothing else? But if you have been doing the sort of things you were talking about with other dialogs then it depends what you did with them.

explorer100

The main window goes invisible, but the other dialogs who have main window as a parent but are non-modal. They stay visible. what I am doing is pressing the X on the top right of the window to test this. and as you said, the app does not actually close (I can see from the IDE that it did not actually close).

SGaist

Closing a window does not mean it gets destroyed immediately. You have multiple top level windows hence your application is still alive due to these other windows.