Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
5.12.2
-
None
-
Windows 10, MinGW 7.3.0
-
-
8957cb2682d874403c3ee08c98bfd544a60c6da4 (qt/qtbase/5.12.3)
Description
If I handle the QEvent::NonClientAreaMouseButtonPress in the widget event() function , then I can query the pressed mouse button by casting the given QEvent to a QMouseEvent and calling its buttons() function or by using the QGuiApplication::mouseButtons(). In both cases the pressed button always is Qt::RightButton although the left button has been pressed.
The strange thing is, that if I close the Window and reopen it again this problem is gone - that means after a close cycle, the right mouse button is returned. The attached test case shows this. The first time the TestWidget is shown, a click into the title bar of the TestWidget with the left mouse button will always increment the counter for the right mouse button. If the TestWidget is closed via its close button and then reopened via the Show Test Widget button, then the counter for the left button is incremented - that means, after the close cycle, it works properly.
I think the bug is related to the bug https://bugreports.qt.io/browse/QTBUG-73295. Because now the NonClientMouseAreaButtonPress event is properly received after a close cycle. So there must be a change that "fixed" the problem with the missing NonClientMouseAreaButtonPress events but introduced a new problem.
I'm the author of the Advanced Qt Docking System https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System and rely on the NonClienteMouseArea events. With every new Qt version I need to implement a new workaround .