CODEWITHSUNDEEP
c++windows
jameszhao00
jameszhao00

Reputation: 7301

Windows Messages Bizarreness

Probably just a gross oversight of some sort, but I'm not receiving any WM_SIZE messages in the message loop. However, I do receive them in the WndProc. I thought the windows loop gave messages out to WndProc?

LRESULT CALLBACK WndProc( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam )
{
    switch(message)
    {
        // this message is read when the window is closed
    case WM_DESTROY:
        {
            // close the application entirely
            PostQuitMessage(0);
            return 0;
        } break;
    case WM_SIZE:
        return 0;
        break;
    }
    printf("wndproc - %i\n", message);
    // Handle any messages the switch statement didn't
    return DefWindowProc (hWnd, message, wParam, lParam);
}

... and now the message loop...

while(TRUE)
{
    // Check to see if any messages are waiting in the queue
    if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
    {

        // translate keystroke messages into the right format
        TranslateMessage(&msg);
        // send the message to the WindowProc function
        DispatchMessage(&msg);

        // check to see if it's time to quit
        if(msg.message == WM_QUIT)
        {
            break;
        }
        if(msg.message == WM_SIZING)
        {
            printf("loop - resizing...\n");
        }
    }
    else
    {
        //do other stuff
    }
}

Upvotes: 2

Views: 721

Answers (3)

Graham Perks
Graham Perks

Reputation: 23398

While you've got hold of the sizing gripper, I believe that Windows is running its own message loop. That will dispatch to your message queue, but your loop is out of the picture while the sizing is ongoing.

The frame window will call SetCapture to capture all subsequent mouse messages. Then it'll resize your window as the mouse moves. It'll also pump the message loop; you can see some similar code here: ftp://ftp.ringdale.com/support/Nlynx/Tech%20Support%20Docs/Midrange/EmeraldSeries/ADK/DDE/C/APITERM/TRACK.C. Note the message loop in the middle of that function.

It pumps the queue itself so that the sizing code doesn't have to return until after the resize tracking is complete.

Edit: I bring up the tracking rectangle code since that's how window resizing used to work, showing just a thin rectangular outline of the window, until we got dynamic window resizing where the entire window updates on the fly while you resize. The behavior internally is likely similar.

Edit 2: Still, credit to the guys who mentioned posted vs sent messages... sent messages won't ever go through the message pump. Sent messages quickly boil down to a function call of your wnd proc. Unless they're sent to windows owned by a different thread, which becomes a lot more complex; they get added to an internal queue belonging to the destination thread's message queue, and are processed internally - before posted messages are returned -inside GetMessage. Getting the sent message's return value back to the source thread involves more gyrations :)

Upvotes: 3

Windows programmer
Windows programmer

Reputation: 8065

WM_SIZING and WM_SIZE are not the same message. I think ordinary mouse operations to resize a window send WM_SIZING first, but if some program sends a WM_SIZE message then you're only going to get WM_SIZE without WM_SIZING.

Upvotes: 0

martona
martona

Reputation: 5914

If a message is sent by the system to your window while it's in DefWindowProc or elsewhere in that netherworld that's the Windows message queue, then that message is not going to be seen by your message loop at all.

Note that this is only true for sent messages. Posted messages will show up in the message loop.

If you want to filter all messages, use SetWindowsHookEx with your thread ID, and the appropriate hook type. Or better yet, process them properly in your WndProc.

Upvotes: 7

Related Questions