Wow, what an exhaustive list. I guess the only thing you didn't mention is the QCoreApplication::aboutToQuit() signalAt least that's what I use for this purpose.
Wow, what an exhaustive list. I guess the only thing you didn't mention is the QCoreApplication::aboutToQuit() signalAt least that's what I use for this purpose.
Thanks both I will test all of your suggestions.
I thought about
Qt Code:
myapp::closeEvent(..... *event) { emit sendcmd(); //here I write my "bye bye" on the device closePort(); // here I close the device event->accept() // here i finally exit the program }To copy to clipboard, switch view to plain text mode
I found that this was not a good idea because:
Before I could write sth on the device "closePort" was called....
I think I should make the "emit sendcmd()" direct connected?? Right?
It will return when all the stuff is finished, so closePort can be executed.
Any other ideas to do that?
I think there is not "return value" for signals which i can check if I can proceed or not.
What exactly are you trying to achieve anyway? If you explain it to us, it'll be easier to suggest some concrete solution.
I try to inform the remote side that my application will be closed and cannot receive anymore.
Instead of forcing the user to click on a "disconnect" button i would do this internal before exiting the program.
It must happen after pressing Alt+F4 or clicking on X and before all the destructors of my objects are called. The whole functionality of the program must still exist in this small time window.
In that case using QCoreApplication::aboutToQuit() or spinning a local event loop after QCoreApplication::exec() returns should suit your situation fine.
Remember that closing a window doesn't destroy it so you can still do everything with its objects until you call delete on it or the object runs out of scope.
Bookmarks