Question

I have found some places that mention window messages are returned by GetMessage in order of priority derived from the way they were sent with SendMessage being highest, than PostMessage and only than user input. However I couldn’t find any authoritative reference, i.e. from Microsoft, on this. The obvious page seems to explicitly deny it (says messages are processed in FIFO order with few exceptions) and I couldn’t find any other reference.

However I have an application behaviour of which suggests there are priorities (several WM_USER thread messages processed each second, yet clicks sometimes take many seconds to get processed). So I would like to know from an authoritative source how it is expected to behave so I can fix the application.

Note: The messages are sent with PostThreadMessage. I am watching messages comming out of GetMessage, so the non-queued messages don’t come into play here. A difference between thread and window messages possibly can.

Note: The application runs on WinCE, 5.0 in particular if it matters.

Answer 1

Hans’s answer is not saying anything different than the linked MSDN documentation.

Messages are processed in first-in, first-out order just like a standard queue, with a couple of special exceptions like WM_TIMER and WM_PAINT messages. Hans refers to this class of messages as those "synthesized from the window state"; MSDN just calls them out explicitly:

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.

The catch is that messages sent with SentMessage are not queued, while those posted with PostMessage are. The same article on MSDN says as much in the next section:

Nonqueued messages are sent immediately to the destination window procedure, bypassing the system message queue and thread message queue.

[…]

Some functions that send nonqueued messages are BroadcastSystemMessage, BroadcastSystemMessageEx, SendMessage, SendMessageTimeout, and SendNotifyMessage.

There are no "priorities". However, the behavior you describe is easily explained. Most likely, the WM_USER messages are sent by calls to the SendMessage function, which bypasses the message queue and sends the message directly to the window procedure for the destination window. That makes them appear to be processed with a higher "priority" because they’re processed immediately, before the SendMessage function returns, effectively bypassing the rest of the queue.

That, in turn, explains why click events take longer to be processed—because they’re just shoved into the queue along with all of the other input messages, so the window doesn’t get around to processing them until after it handles the messages sent directly to it with calls to SendMessage.

_{Important caveat: I know nothing about Windows CE, which your question indicates you’re talking about specifically. The behavior I describe here is accurate for desktop versions of Windows, but if there are any differences between that behavior and that of Windows CE, I wouldn’t know and I might have gotten something wrong.}