QMainWindow misses close event messages from Windows Taskbar
-
Hi,
There's something not clear here, do you mean that when you click on "close window", closeEvent is never called or it's called from time to time ?
-
Could you find a pattern for that like e.g. doesn't work when hidden etc. ?
-
yep I had something like that into my Qt on Linux Kubuntu 14.04. As far as i remember it was a pointer problem (undetected sigpipe) difficult to find it but after spending a lot I've found it in my main.cpp I will inform you as soon as I'll find it.. I have saved some info about this somewhere. happened only on Linux - I do not remember if in windows too
-
have a look "here":http://qt-project.org/forums/viewthread/45163/
All credit to SGaist
hope this will help you -
Thanks guys,
I have more details. When I try to close from taskbar (win7, qt5.3), even if closeEvent is not generated, the window takes focus anyway and a beep signal is emitted (the same beep on windows when your are trying to close while some dialog is waiting for input from the user). This is strange cause I do not have any dialog.
I will investigate more and let you know.
Thanks
Fabio -
Hi all,
After one morning of tests, I discovered what happens (not why):
In my application I have a QMdiArea with MdiDocumentViewer that inherits QMdiSubwindow. Looking at event polling, I tracked events:
When you close the main window, first some events are sent to all internal widgets of the QMdiArea to change their state, and then, in case of success, the QMainWindow.closeEvent is actually invoked.I discovered that the invocation of MdiDocumentViewer.event when event is QWindowStateChange event (invoked just before QMainWindow.closeEvent) sometimes fails (the result of event->isAccepted() is false), sometimes not. At the moment it is absolutely random (I simply try to close more and more times until it successes).
Really don't know why.
Thanks
-
Strange indeed… Which version of Windows and Qt ?
-
Hi SGaist,
After tracking MS windows events. I checked that closing from task ber gets the WindowStataChange(WindowActive) event raised that, in turn, at some point of my code, invokes QClipboard::text(). The latter method invocation makes the WindowStateChange message rejected (strangely) . Commenting the latter invocation, everything works well. So, now the question is: why QClipboard::text() invoked inside the MSWin event dispatching loop works in this way? Of couser, QClipboard interacts with the MSWindows clipboard. IMHO it is a Qt bug.
Anyway I solved it simpling putting that QClipboard invocation somewhere else.
Fabio
-
There might be something up. You should have a look at the "bug report system":http://bugreports.qt-project.org to see if something like that has already been reported. If not, please consider opening a new report providing a minimal compilable example showing how to reproduce the behavior.