Windows 11 PeekMessage() not returning WM_KEYDOWN message

Alex Sokolek · May 3, 2024

Hi. I'm having trouble with PeekMessage(). I use PeekMessage() in a loop inside my WM_PAINT procedure to consume messages generated during a long computation process, and to allow the user to abort the process by pressing ESCAPE. Here is a snippet of my code...

Code:

... Create several threads to do some lengthy work
        // Wait for all threads to terminate.
        for (;;)
        {
            // Wait for up to fifty milliseconds.
            if (WaitForMultipleObjects(Threads, phThreadArray, TRUE, 50) == WAIT_OBJECT_0) break;
            
            // Update the user about progress.
            int Slice = wq->getSlices();
            int iPercent = (int)((Slices - Slice) * 100.f / Slices + 0.5f);
            StringCchPrintf(szProgress, 100, _T("Slice: %d of %d (%d%%)"), Slices - Slice, Slices, iPercent);
            SetBkColor(dc, RGB(240, 240, 240));
            TextOut(dc, 16, 16, szProgress, lstrlen(szProgress));
            TextOut(dc, 16, 40, _T("Press ESC to abort"), 19);

            // Flush the message queue and check for abort request.
            MSG msg;
            if (!PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE)) continue; // Case of no message.
            TCHAR sz[50];
            StringCchPrintf(sz, 50, _T("%08x   %016x\n"), msg.message, msg.wParam);
            OutputDebugString(sz);
            if (msg.message == WM_KEYDOWN && msg.wParam == VK_ESCAPE) bAbort = true;
        }
... Clean up and display results

I used OutputDebugString() to display the message code and wparam values. I never get a WM_KEYDOWN message (0x0100). I should, when I press ESCAPE during the lengthy execution. Any ideas? Thanks.

Alex Sokolek · May 4, 2024

This problem has been resolved. The solution involved replacing "PeekMessage(&msg, hWnd, WM_KEYFIRST, 0, 0, PM_REMOVE)" with "PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)". The reason I did not think it was the solution before was that I was also throwing an access exception (in a different part of my code) and I was confused as to it's source. Thank you.

ChatGPT · May 3, 2024

From your given code snippet, it seems like you're doing quite a bit in your WM_PAINT handling - including performing long computations and initiating multiple threads which, whilst possible, isn't generally advised. However, I understand that this situation may require it, and I'll focus on the issue mentioned: PeekMessage() does not return WM_KEYDOWN (0x0100) in your debug output. There could be a few reasons for this:

Message Loop Issue: The most common reason is that the input messages(i.e., WM_KEYDOWN and WM_KEYUP) are being dispatched to the other part of your application. Instead of PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE) which only checks messages for your concrete window, you could try changing this to PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) (NULL implies messages for any window belonging to the current thread), which checks all the thread's messages.
Priority of Messages: WM_PAINT is a low priority message. Windows ignores WM_PAINT message if there are other messages in the message queue for a particular application. And since you are running a loop for lengthy computations and thread waits inside WM_PAINT, there are chances that your WM_KEYDOWN is being overridden. You might want to reconsider this design approach.
Keyboard Issue: Check if ESCAPE key is working fine. Try with some other key for confirmation.
Thread Issue: You mentioned you're using threads. Depending on how this is implemented, there can be issues between threads and the Windows message pump which might cause messages to be lost. Make sure your approach to threading in this case does not interfere with the message loop. If you're not very certain, you could try posting a minimum reproduction case so we can understand more fully where the issue may be coming from. Let me know if these suggestions help.

Alex Sokolek · May 3, 2024

ChatGPT said:
From your given code snippet, it seems like you're doing quite a bit in your WM_PAINT handling - including performing long computations and initiating multiple threads which, whilst possible, isn't generally advised.

However, I understand that this situation may require it, and I'll focus on the issue mentioned: PeekMessage() does not return WM_KEYDOWN (0x0100) in your debug output. There could be a few reasons for this:

1. **Message Loop Issue**: The most common reason is that the input messages(i.e., WM_KEYDOWN and WM_KEYUP) are being dispatched to the other part of your application.

Instead of `PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE)` which only checks messages for your concrete window, you could try changing this to `PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)` (NULL implies messages for any window belonging to the current thread), which checks all the thread's messages.

2. **Priority of Messages**: WM_PAINT is a low priority message. Windows ignores WM_PAINT message if there are other messages in the message queue for a particular application. And since you are running a loop for lengthy computations and thread waits inside WM_PAINT, there are chances that your WM_KEYDOWN is being overridden. You might want to reconsider this design approach.

3. **Keyboard Issue**: Check if ESCAPE key is working fine. Try with some other key for confirmation.

4. **Thread Issue**: You mentioned you're using threads. Depending on how this is implemented, there can be issues between threads and the Windows message pump which might cause messages to be lost.

Make sure your approach to threading in this case does not interfere with the message loop. If you're not very certain, you could try posting a minimum reproduction case so we can understand more fully where the issue may be coming from.

Let me know if these suggestions help.

"ChatGPT"

1. I tried PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) and that did not help.

2. I could understand that, if the priority of WM_PAINT vs WM_KEYDOWN were reversed. If this were the issue, I would expect that WM_KEYDOWN would have priority over WM_PAINT. Besides, I have another program that checks for ESCAPE inside WM_PAINT and that program works fine. (Yes, I will compare and see if there is any remedy with the other paradigm. The other program does not use threads, so the wait loop is different.)

3. ESCAPE is working fine. I also checked with several other keys. I never get a WM_KEYDOWN message.

4. My threads don't do any GUI work at all. They only compute the pixels for the Mandelbrot set, using a memory based bitmap. After the wait loop is done, I BITBLT the bitmap to the DC for the window using SetDIBitsToDevice(). I do this in the main program thread.

My approach to threading is simple. I call CreateThread() 12 times, after filling a FIFO with slices to work on. The threads are initially stalled, waiting on a mutex to proceed. I release the mutex, and the threads take off. Then I enter the wait loop shown above.

I will review your suggestions. I will post new snippets if I need to. Again, thank you.

Alex Sokolek · May 3, 2024

"ChatGPT"

1. I checked. VK_ESCAPE is 0x1B and WM_KEYDOWN is 0x0100.

2. I tried TranslateMessage(). It did not help. Besides, the docs say that TranslateMessage() directly sends the translated messages to the Windows Procedure.

3. I don't think GetMessage() would work. It does not return until there is a message. Besides, I think that would result in a deadlock situation as I'm already in a WM_PAINT handler.

4. I used WM_KEYFIRST, WM_KEYLAST in another program. It resulted in the Windows Display Manager marking my application as "non-responsive". Since I use 0,0 I remove all messages, and then filter with "if (msg.message == WM_KEYDOWN && msg.wParam == VK_ESCAPE) bAbort = true;"

5. I don't think there is any conflict with System Level Hotkeys. I only use ESCAPE, without any Ctrl, Alt, or Shift modifier.

6. I don't think I have a focus problem. I thought about that and tried clicking on the window and then on the modeless dialog box berfore pressing ESCAPE. That did not change anything.

I still have some research to do. I'll do that and get back to you. Thank you.

Alex Sokolek · May 4, 2024

This problem has been resolved. The solution involved replacing "PeekMessage(&msg, hWnd, WM_KEYFIRST, 0, 0, PM_REMOVE)" with "PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)". The reason I did not think it was the solution before was that I was also throwing an access exception (in a different part of my code) and I was confused as to it's source. Thank you.

Windows 11 PeekMessage() not returning WM_KEYDOWN message

Alex Sokolek

Member

Alex Sokolek

ChatGPT

AI

Alex Sokolek

Member

Alex Sokolek

Member

Alex Sokolek

Member

Similar threads