Order of signals on application quitting
-
In my main window I defined an action to quit the application, and I've overriden the closeEvent method to handle some before-exiting behaviour. Now, it is correct to assume that the following:
@
connect( actionQuit,
SIGNAL(triggered()),
this,
SLOT(close()) );
connect( actionQuit,
SIGNAL(triggered()),
qApp,
SLOT(quit()) );
@will always call issue the QCloseEvent and only after exits the application?
-
issue yes, but handle no.
The point is, that the close event will be pushed in the event queue, directly after which the call to qApp->quit is made. That means that whatever happens in qApp->quit is executed before the QCloseEvent is handled, as the application has not returned to the eventloop yet. That would only happen if all the connected signals have been invoked, but in this case, qApp->quit just might get rid of the entire event queue or something like that.
What you could try to do, is make your second connect a queuedConnection. That way, it will be handled only when the eventloop is running again, and the event queue will already have the QCloseEvent on it by then.
-
And what if I leave the qApp.quit slot connected and perform the pre-exit behaviour in the main window destructor? I guess qApp will free memory on exit, so the destructor will be called anyway, right? Moreover I could set the Qt::WA_deleteOnclose attribute of the main window to force the deletion when the window is closed. Could it work?
-
I think the behaviour is partly undocumented, but it cannot be changed:
the slots will be invoked in that order (first close(), then quit());
close() will post a QCloseEvent;
quit() will tell the event loop to exit.
edited -- I stand up corrected, better avoid to leave false statements around
-
The point here is if the event loop is flushed or not, that is if all events are delivered or the application simply aborts. The "exit":http://doc.qt.nokia.com/4.7/qcoreapplication.html#exit documentation says that
bq. After this function has been called, the application leaves the main event loop and returns from the call to exec()
and if I get it right, it is not safe to assume the event queue will be flushed.
-
[quote author="fluca1978" date="1317204693"]And what if I leave the qApp.quit slot connected and perform the pre-exit behaviour in the main window destructor? I guess qApp will free memory on exit, so the destructor will be called anyway, right? Moreover I could set the Qt::WA_deleteOnclose attribute of the main window to force the deletion when the window is closed. Could it work?[/quote]
I really think this should work. surely the object will be deleted on program exit, and I think each object destructor is called.
Paolo
