Changeset 21955 for trunk/src/user32/oslibmsg.cpp

Timestamp:

Jan 31, 2012, 10:25:42 PM (14 years ago)

Author:

dmik

Message:

Make sure GetQueueStatus() correctly reports QS_KEY state.

Due to a bug in WinQueryQueueStatus(), QS_KEY would be
always set on return if the associated window is active, even
if there were no WM_CHAR messages actually in the queue.
This broke the newer Flash (see Flash #39 for details).

GetInputState() was also affected by this problem; it would always
return TRUE for active windows.

File:

• trunk/src/user32/oslibmsg.cpp (modified) (1 diff)

trunk/src/user32/oslibmsg.cpp

@@ -548 +548 @@
 //TODO: QS_HOTKEY
 //******************************************************************************
-ULONG OSLibWinQueryQueueStatus()
+ULONG OSLibWinQueryQueueStatus(ULONG flags)
 {
     ULONG statusOS2, statusWin32 = 0;
 
     statusOS2 = WinQueryQueueStatus(HWND_DESKTOP);
+    dprintf(("*** 3 %x", statusOS2));
+
+    if (flags & QS_KEY)
+    {
+        // WinQueryQueueStatus() has a bug which causes it to always return
+        // the QS_KEY bit set when the associated window is active, regardless
+        // of whether thiere are WM_CHAR messages in the queue or not. We try to
+        // fix this by looking up the queue ourselves if the caller actually
+        // wants this state to be checked
+        QMSG qmsg;
+        BOOL haveKey = WinPeekMsg (0, &qmsg, 0, WM_CHAR, WM_CHAR, PM_NOREMOVE);
+        if (haveKey)
+        {
+            // set the proper "summary" status
+            statusOS2 |= (QS_KEY << 16);
+        }
+        else
+        {
+            statusOS2 &= ~(QS_KEY << 16);
+            // according to PMREF, the "added" field is a subset of the
+            // "summary" field, so it makes no sense to have it set when it is
+            // reset in "summary"
+            statusOS2 &= ~(QS_KEY);
+        }
+    }
 
     // convert the flags since last call (low word)