From 1900ef3c9805d7fe15e0634cef9b5ff2a5dc7838 Mon Sep 17 00:00:00 2001
From: SineStriker <trueful@163.com>
Date: 周三, 20 12月 2023 20:02:05 +0800
Subject: [PATCH] minor tweaks
---
src/core/contexts/win32windowcontext.cpp | 80 ++++++++++++++++++++++++++++++++++++----
1 files changed, 72 insertions(+), 8 deletions(-)
diff --git a/src/core/contexts/win32windowcontext.cpp b/src/core/contexts/win32windowcontext.cpp
index cd1ab62..7a8ad24 100644
--- a/src/core/contexts/win32windowcontext.cpp
+++ b/src/core/contexts/win32windowcontext.cpp
@@ -845,6 +845,7 @@
g_wndProcHash->insert(hWnd, ctx);
}
+ template <bool Destroyed = true>
static inline void removeManagedWindow(HWND hWnd) {
// Remove window handle mapping
if (!g_wndProcHash->remove(hWnd))
@@ -853,6 +854,11 @@
// Remove event filter if the all windows has been destroyed
if (g_wndProcHash->empty()) {
WindowsNativeEventFilter::uninstall();
+ }
+
+ // Restore window proc
+ if constexpr (!Destroyed) {
+ ::SetWindowLongPtrW(hWnd, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(g_qtWindowProc));
}
}
@@ -911,7 +917,7 @@
}
}
- break;
+ return;
}
case DefaultColorsHook: {
@@ -964,10 +970,8 @@
return;
}
- default: {
- // unreachable
+ default:
break;
- }
}
AbstractWindowContext::virtual_hook(id, data);
}
@@ -980,8 +984,19 @@
return getWindowFrameBorderThickness(reinterpret_cast<HWND>(windowId));
}
- void Win32WindowContext::winIdChanged(QWindow *oldWindow) {
- removeManagedWindow(reinterpret_cast<HWND>(windowId));
+ void Win32WindowContext::winIdChanged(QWindow *oldWindow, bool isDestroyed) {
+ Q_UNUSED(isDestroyed)
+
+ // If the original window id is valid, remove all resources related
+ if (windowId) {
+ if (isDestroyed) {
+ removeManagedWindow(reinterpret_cast<HWND>(windowId));
+ } else {
+ removeManagedWindow<false>(reinterpret_cast<HWND>(windowId));
+ }
+ windowId = 0;
+ }
+
if (!m_windowHandle) {
return;
}
@@ -1001,7 +1016,7 @@
#endif
// Inform Qt we want and have set custom margins
- updateInternalWindowFrameMargins(hWnd, m_windowHandle);
+ updateInternalWindowFrameMargins(hWnd, m_windowHandle); // TODO: Restore?
// Add managed window
addManagedWindow(hWnd, this);
@@ -1268,6 +1283,53 @@
const WindowPart currentWindowPart = lastHitTestResult;
if (message == WM_NCMOUSEMOVE) {
if (currentWindowPart != WindowPart::ChromeButton) {
+ // https://github.com/qt/qtbase/blob/e26a87f1ecc40bc8c6aa5b889fce67410a57a702/src/widgets/kernel/qwidgetwindow.cpp#L472
+ // When the mouse press event arrives, QWidgetWindow will implicitly grab
+ // the top widget right under the mouse, and set `qt_button_down` to this
+ // widget. At this time, no other widgets will accept the mouse event until
+ // QWidgetWindow receives the mouse release event, then set `qt_button_down`
+ // to null.
+
+ // Imagine the following situation, now the main window has a pop-up menu,
+ // the focus is not on the main window, if we click outside the pop-up menu,
+ // the menu will close, which seems to be completely fine. But if we close
+ // the menu by clicking on the title bar draggable area, then other widgets
+ // won't accept the mouse message afterwards.
+
+ // Here's the reason.
+ // When the mouse is placed in the draggable area of the title bar, there
+ // are two situations.
+
+ // 1. If the focus is on the main window, and the last result of
+ // WM_NCHITTEST is HTCAPTION, the mouse click event in the title bar is
+ // taken over by Windows and Qt does not receive the mouse click event.
+
+ // 2. If the main window has a pop-up menu, it is completely different. When
+ // the mouse is pressed on the title bar, Windows sends the WM_LBUTTONDOWN
+ // message to the window plane of the pop-up menu, the menu is closed, but
+ // Qt will continue to forward the event to the QWidget under the mouse, and
+ // the event will be processed by QWidgetWindow, causing the title bar
+ // widget to be implicitly grabbed. After the menu is closed, Windows
+ // immediately sends WM_NCHITTEST, because the mouse is in the title bar
+ // draggable area, the result is HTCAPTION, so when the mouse is released,
+ // Windows sends WM_NCLBUTTONUP, which is a non-client message, and it
+ // will be ignored by Qt. As a consequence, QWidgetWindow can't receive a
+ // mouse release message in the client area, so the grab remains, and other
+ // widgets cannot receive mouse events.
+
+ // Since we didn't watch the menu window, we cannot capture any mouse
+ // press events sent by Windows, so we cannot solve this problem by
+ // recording mouse events. Fortunately, we found that the main window will
+ // receive a WM_NCMOUSEMOVE message immediately after the menu is closed, so
+ // we just manually send a mouse release event when this message arrives and
+ // set qt_button_down to null. Don't worry, when receiving WM_NCMOUSEMOVE,
+ // there shouldn't be any control in the state of being grabbed.
+
+ // In the native window, although QWidgetWindow handles the forwarded mouse
+ // press event when the menu is closed, since the native title bar is not a
+ // QWidget, no widget will be grabbed, and `qt_button_down` remains empty,
+ // the above problems would not arise.
+
m_delegate->resetQtGrabbedControl(m_host);
if (mouseLeaveBlocked) {
emulateClientAreaMessage(hWnd, message, wParam, lParam,
@@ -1330,6 +1392,8 @@
// window from client area, which means we will get previous window part as
// HTCLIENT if the mouse leaves window from client area and enters window
// from non-client area, but it has no bad effect.
+
+ // Why do we need to call this function here?
m_delegate->resetQtGrabbedControl(m_host);
}
}
@@ -1561,7 +1625,7 @@
*result = (isTitleBar ? HTCAPTION : HTCLIENT);
return true;
}
- // At this point, we know that the cursor is inside the client area
+ // At this point, we know that the cursor is inside the client area,
// so it has to be either the little border at the top of our custom
// title bar or the drag bar. Apparently, it must be the drag bar or
// the little border at the top which the user can use to move or
--
Gitblit v1.9.1