WM_PAINT message is queued message or Nonqueued Messages?

1
votes

In this article About Messages and Message Queues, it was said that WM_PAINT is kind of Queued Messages.

Queued Messages

Whenever the user moves the mouse, clicks the mouse buttons, or types on the keyboard, the device driver for the mouse or keyboard converts the input into messages and places them in the system message queue. The system removes the messages, one at a time, from the system message queue, examines them to determine the destination window, and then posts them to the message queue of the thread that created the destination window. A thread's message queue receives all mouse and keyboard messages for the windows created by the thread. The thread removes messages from its queue and directs the system to send them to the appropriate window procedure for processing.

With the exception of the WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, the system always posts messages at the end of a message queue. This ensures that a window receives its input messages in the proper first in, first out (FIFO) sequence. The WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, however, are kept in the queue and are forwarded to the window procedure only when the queue contains no other messages. In addition, multiple WM_PAINT messages for the same window are combined into a single WM_PAINT message, consolidating all invalid parts of the client area into a single area. Combining WM_PAINT messages reduces the number of times a window must redraw the contents of its client area.

But according to the book "programming windows"

However, the window procedure could call a function that sends the window procedure another message, in which case the window procedure must finish processing the second message before the function call returns, at which time the window procedure proceeds with the original message. For example, when a window procedure calls UpdateWindow, Windows calls the window procedure with a WM_PAINT message. When the window procedure finishes processing the WM_PAINT message, the UpdateWindowcall will return controls back to the window procedure.

If the WM_PAINT is queued message, it should be added to the message queue. so it will not process until current message and all the other messages in the message queue have been processed. which is controversy with the statement above.

I am wondering which is correct, Thanks.

2
windowswinapi
Messages are sent, posted or synthesized from the window state. WM_PAINT falls in the latter category, generated when the window's update rectangle isn't empty. And there are no sent or posted messages remaining. WM_MOUSEMOVE is another one, more obliquely, you don't get that message for every single pixel that the mouse traversed. – Hans Passant

2 Answers

2
votes

Any message can be sent directly to a window proceudure using SendMessage or posted to the window's message queue using PostMessage. The UpdateWindow function uses SendMessage to send a WM_PAINT message directly to a window procedure so that the window is redrawn immediately. When the system needs the window to be redrawn for whatever reason it normally posts the message to the window's message queue.

So WM_PAINT isn't a queued (posted) message, nor is at a sent message. It's just a message. It either can be sent or posted. Some messages are only meant to be send or posted, but WM_PAINT isn't one of them.

1
votes

Here is the document about UpdateWindow function from MSDN

The UpdateWindow function updates the client area of the specified window by sending a WM_PAINT message to the window if the window's update region is not empty. The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue. If the update region is empty, no message is sent.