does not return from exec()

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.

JonB

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

. its the other dialogs who have main window as a parent but are non-modal.

But you haven't shown what you do in the code you posted, there are no other dialogs. So we don't know what you do with them. If instead of calling exec() on them you call show() you may have to close them yourself explicitly, I can't recall. QDialog uses its parent parameter differently from other widgets/windows, per the docs for it.

https://doc.qt.io/qt-6/qdialog.html#details

A dialog window is a top-level window mostly used for short-term tasks and brief communications with the user. QDialogs may be modal or modeless.

Note that QDialog (and any other widget that has type Qt::Dialog) uses the parent widget slightly differently from other classes in Qt. A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent's top-level widget (if it is not top-level itself). It will also share the parent's taskbar entry.

So QDialogs are always top-level windows, regardless of parent, IIRC. In which case you would need to close any modeless dialogs you created before app.exec() will return. QDialog::exec() works because it waits for the dialog to be exited and then closes it; QDialog::open() does not wait or close, so the dialog stays around.

explorer100

OK. If I understand it correctly, modeless dialogs that are activated using show() stay around and need to be closed explicitly. But it seems they are holding the app from closing. Is there a way (a slot like approach) to catch the exit/reject from main window and do some cleanups? Like closing open dialogs? I am using dialogs almost as permanent fixtures that also talk to each other (and in some cases also open and close each other) while the application is running. It's just the nature of the application... Lots of decentralized displays that will be laid out on multiple large screens. Without dialogs, the application closes completely just fine. It is the dialogs that are holding it up.

JonB

@explorer100
Having subclassed QMainWindow, you can override its virtual closeEvent() to detect the user is closing it.

From there you could close all open dialogs. You should presumably have a kept an array of the ones you opened as you opened them? https://doc.qt.io/qt-6/qtwidgets-tutorials-widgets-toplevel-example.html

If a widget is created without a parent, it is treated as a window, or top-level widget, when it is shown. Since it has no parent object to ensure that it is deleted when no longer needed, it is up to the developer to keep track of the top-level widgets in an application.

Or you can probably use QWindowList QGuiApplication::topLevelWindows() to look through and close them (perhaps checking if they are QDialogs, certainly don't try to close the MainWindow from within its own closeEvent()!).

Or from MainWindow::closeEvent() you might be able to call QApplication::exit() or quit() directly, instead of waiting for Qt to see that all top-level windows or closed. Though this one might be a bit "abrupt" (quit() might be better than exit()), maybe it's better to actually close your dialogs per the previous approaches.

explorer100

Thank you so much for the information and suggestions. will try some of these approaches and report back on what worked best and why.