Сообщения Windows Bizarreness

Question

Возможно, просто какой-то грубый недосмотр, но я не получаю никаких сообщений WM_SIZE в цикле сообщений. Тем не менее, я получаю их в WndProc. Я думал, что цикл Windows дает сообщения 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);
}

... а теперь цикл сообщений ...

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
    }
}

Answer 1

Если сообщение отправляется системой в ваше окно, пока оно находится в DefWindowProc или в другом месте в этом потустороннем мире, являющемся очередью сообщений Windows, то это сообщение вообще не будет видимо вашим циклом сообщений.

Обратите внимание, что это верно только для отправленных сообщений.Отправленные сообщения будут отображаться в цикле сообщений.

Если вы хотите отфильтровать все сообщения, используйте SetWindowsHookEx с вашим идентификатором потока и соответствующим типом ловушки.Или, что еще лучше, обработайте их должным образом в WndProc.

Answer 2

Несмотря на то, что у вас есть средство для определения размеров, я считаю, что Windows запускает свой собственный цикл обработки сообщений. Это отправит в вашу очередь сообщений, но ваша петля выходит за рамки изображения, в то время как определение размера продолжается.

Окно фрейма вызовет SetCapture для захвата всех последующих сообщений мыши. Затем он будет изменять размер вашего окна при движении мыши. Это также прокачает цикл сообщений; Вы можете увидеть похожий код здесь: ftp: //ftp.ringdale.com/support/Nlynx/Tech%20Support%20Docs/Midrange/EmeraldSeries/ADK/DDE/C/APITERM/TRACK.C. Обратите внимание на цикл обработки сообщений в середине этой функции.

Он сам прокачивает очередь, так что код определения размера не должен возвращаться до тех пор, пока не будет завершено отслеживание изменения размера.

Редактировать: Я поднимаю код отслеживания прямоугольника, так как так работало изменение размера окна, показывая только тонкий прямоугольный контур окна, пока мы не получили динамическое изменение размера окна, где все окно обновляется на лету, пока вы изменяете размер. Внутреннее поведение, вероятно, аналогично.

Редактировать 2: Тем не менее, спасибо парням, которые упоминали опубликованные и отправленные сообщения ... отправленные сообщения никогда не пройдут через насос сообщений. Отправленные сообщения быстро сводятся к вызову функции вашего wnd proc. Если они не отправлены в окна, принадлежащие другому потоку, который становится намного более сложным; они добавляются во внутреннюю очередь, принадлежащую очереди сообщений целевого потока, и обрабатываются внутри - до того, как отправленные сообщения возвращаются - внутри GetMessage. Возвращение возвращаемого значения отправленного сообщения в исходный поток требует большего количества вращений:)

Answer 3

WM_SIZING и WM_SIZE - это не одно и то же сообщение. Я думаю, что обычные операции с мышью для изменения размера окна сначала отправляют WM_SIZING, но если какая-то программа отправляет сообщение WM_SIZE, то вы получите только WM_SIZE без WM_SIZING.