我发现some places提到窗口消息是由GetMessage以优先顺序返回的，这些优先级来自SendMessage最高发送方式，而不是PostMessage而且只是用户输入。但是，我无法找到任何权威参考，即来自Microsoft。 obvious page似乎明确拒绝它（说消息按FIFO顺序处理，除了少数例外），我找不到任何其他参考。
但是我的应用程序行为表明存在优先级（每秒处理几个WM_USER 线程消息，但点击有时需要很长时间才能处理）。所以我想从一个权威来源知道它应该如何表现，以便我可以修复应用程序。
注意：消息随PostThreadMessage一起发送。我正在观看来自GetMessage的消息，因此不排队的消息不会在这里发挥作用。线程和窗口消息之间的区别可能是。
注意：应用程序在WinCE 5.0上运行，特别是如果重要的话。
答案 0 :(得分：2)
Hans's answer与the linked MSDN documentation没有任何不同。
消息以先进先出的顺序处理，就像标准队列一样，有一些特殊的例外，例如WM_TIMER和WM_PAINT消息。汉斯将这类消息称为“从窗口状态合成”的消息; MSDN只是明确地调用它们：
除了
WM_PAINT消息，WM_TIMER消息和WM_QUIT消息之外，系统始终在消息队列的末尾发布消息。这确保了窗口以适当的先进先出（FIFO）顺序接收其输入消息。但是，WM_PAINT消息，WM_TIMER消息和WM_QUIT消息将保留在队列中，并仅在队列不包含其他消息时转发到窗口过程。此外，同一窗口的多个WM_PAINT消息将合并为一条WM_PAINT消息，将客户区的所有无效部分合并到一个区域中。组合WM_PAINT消息可减少窗口必须重绘其客户区域内容的次数。
问题在于，使用SentMessage发送的邮件未排队，而使用PostMessage 发布的邮件是。 MSDN上的同一篇文章在next section中说的很多：
非排队消息立即发送到目标窗口过程，绕过系统消息队列和线程消息队列。
[...]
发送非排队邮件的一些函数包括
BroadcastSystemMessage，BroadcastSystemMessageEx，SendMessage，SendMessageTimeout和SendNotifyMessage。
没有“优先事项”。但是，您描述的行为很容易解释。最有可能的是，WM_USER消息是通过调用SendMessage函数发送的，该函数绕过消息队列并将消息直接发送到目标窗口的窗口过程。这使得它们似乎被处理为具有更高的“优先级”，因为它们在SendMessage函数返回之前立即被处理，有效地绕过队列的其余部分。
反过来，这解释了为什么点击事件需要更长的时间来处理 - 因为它们只是与所有其他输入消息一起被推入队列，因此窗口不会在它之后处理它们通过调用SendMessage来处理直接发送给它的消息。
重要警告：我对Windows CE一无所知，您的问题表明您正在谈论具体问题。我在这里描述的行为对于Windows的桌面版本是准确的，但如果该行为与Windows CE的行为之间存在任何差异，我不会知道，我可能会遇到问题。