September 28, 2011

fluca1978 fluca1978
Ant Farmer
524 posts

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:

  1. connect( actionQuit,
  2.              SIGNAL(triggered()),
  3.              this,
  4.              SLOT(close()) );
  5.     connect( actionQuit,
  6.              SIGNAL(triggered()),
  7.              qApp,
  8.              SLOT(quit()) );

will always call issue the QCloseEvent and only after exits the application?

5 replies

September 28, 2011

Andre Andre
Area 51 Engineer
6031 posts

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.

 Signature 

Looking for Qt developers to join our team @ i-Optics: https://qt-project.org/forums/viewthread/25393/

September 28, 2011

fluca1978 fluca1978
Ant Farmer
524 posts

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?

September 28, 2011

peppe peppe
Ant Farmer
1025 posts

I think the behaviour is partly undocumented, but it cannot be changed:

  1. the slots will be invoked in that order (first close(), then quit());
  2. close() will post a QCloseEvent;
  3. quit() will tell the event loop to exit.

edited — I stand up corrected, better avoid to leave false statements around

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

September 28, 2011

fluca1978 fluca1978
Ant Farmer
524 posts

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 [doc.qt.nokia.com] documentation says that

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.

September 28, 2011

p91paul p91paul
Lab Rat
33 posts
fluca1978 wrote:
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 really think this should work. surely the object will be deleted on program exit, and I think each object destructor is called.
Paolo

 
  ‹‹ QSlider styling: making space to the right      Next & Previous line in a text file at N bytes position (N = middle) ››

You must log in to post a reply. Not a member yet? Register here!