如何解释这种奇怪的 PeekMessage 行为（尝试处理完整的消​​息队列，过滤特定消息）？

Question

我们的应用程序充当 COM 服务器，其中所有自动化都发生在单个 STA 单元（在应用程序的主线程中）内，并且一些进行长时间（> 10 分钟）调用的 VBS 脚本失败，并出现错误“系统调用失败 (80010100)” ”。一些研究（一个，< a href="https://stackoverflow.com/questions/123323/how-deep-is-the-win32-message-queue">两个，三）表示这可能是由消息引起的队列已满，因此当 COM 尝试调用下一个方法时，它无法调用。

如果重要的话，该应用程序是使用 Embarcadero RAD Studio 2010 开发的（主要是C++，一些 Delphi 对于某些 COM 类。）

我想我应该在末尾检查线程的消息队列冗长的 COM 方法调用（即在它返回之前）通过使用 GetQueueStatus和 PeekMessage 。虽然队列似乎已满，但我看到一些奇怪的行为，并且无法弄清楚为什么 PeekMessage 的行为方式如此，以及队列已满的确切原因 - 即，它充满了什么。

前面的解释有点长：

测试线程的消息队列已满

代码如下：

int iMessages = 0;
DWORD dwThreadId = GetCurrentThreadId();
while (::PostThreadMessage(dwThreadId, WM_USER, 0, 0)) {
  iMessages++;
}
if (GetLastError() == ERROR_NOT_ENOUGH_QUOTA) {
  String strError = L"Not enough quota, posted " + IntToStr(iMessages) + L" messages";
  // Do something with strError
}

当在短的 COM 调用方法结束时运行时，可以发布数千条（例如 9996 条）消息；在导致脚本失败的冗长方法调用结束时，它可以发布 0。我的结论是消息队列已满确实是问题的原因。我的系统的消息队列限制是默认 10000（请参阅备注部分。）

对 Application->ProcessMessages() 的调用（调用应用程序的消息循环，直到它为空，对于那些不是 Delphi / C++Builder 用户的人来说 - 这是一个相当正常的“获取/翻译/调度，直到没有更多消息”方法）解决了问题，COM 脚本可以成功调用next方法。虽然在这种特定情况下可能没问题，但在有效的随机点调用 ProcessMessages() 是需要避免的——它可能导致重入。如果可能的话，我想找出导致队列满的原因。

检查消息队列的内容

使用 GetQueueStatus 确定队列中的消息类型，显示有计时器 (QS_TIMER)、已发布消息(QS_POSTMESSAGE)、“所有已发布的消息”（即其他已发布的消息，QS_ALLPOSTMESSAGE）和绘制消息 (QS_PAINT)。

这就是奇怪的地方。我正在尝试使用 PeekMessage 和 PM_REMOVE 可以部分清空队列并计算每种类型的数量 信息。

如果我打电话：

while (::PeekMessage(&oMsg, NULL, 0, 0, PM_REMOVE | PM_NOYIELD | (QS_TIMER << 16)) != 0) {...

我会收到一万多条消息，通常是 10006 条左右。并非所有消息都是 WM_TIMER：有数千个消息是 WM_APP+202，这是我们内部使用的消息，但似乎没有（由我们）以如此大的数量发布（由我们）。我检查过：它只发送了几次。我们还使用了数千条其他 WM_APP+something 消息；这可能确实发送得太频繁了。

如果我这样调用：

while (::PeekMessage(&oMsg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE | PM_NOYIELD) != 0) {...

我会收到大约十条消息，所有这些消息都是真正的 WM_TIMER。为什么？ PeekMessage 文档表明传递 QS_TIMER << 16 应该只处理计时器消息，但它会产生更多的消息，其中许多根本不是计时器。

最后，如果我调用第三种变体：

while (::PeekMessage(&oMsg, NULL, WM_APP+202, WM_APP+202, PM_REMOVE | PM_NOYIELD) != 0) {...

直接过滤第一行代码返回数千条的自定义消息，我会删除十七条消息。

我已经将这一切重复了好几次——没有一个是一次性的行为。

那么：

• 为什么第一次调用 PeekMessage 删除的不仅仅是计时器（与第二次调用相比）？只是好奇心，真的。
• 为什么对 PeekMessage 的第一次调用会删除数千条 WM_APP+202 消息（我们定义和使用的消息，但不会发送那么多消息），但如果我而是调用第三个变体，它会直接过滤对于该特定消息，我得到 17？
• 如果我对同一条消息得到如此不同的结果，我如何找出队列中填满了什么以及如何最好地避免它？
• 或者为了避免上述所有情况：我可以安全地忽略所有这些，那么当 COM 即将尝试调用一个方法时，我应该如何处理完整的消​​息队列呢？

我很困惑，而且很可能犯了一个低级错误——在你这样做的时候，你会看到一些令人费解的东西。对于 COM 问题的任何帮助或消息行为的解释，包括“你犯了基本错误 X，天哪，你太愚蠢了”，我们将不胜感激:)

Answer 1

GetQueueStatus() 接受 QS_xxx 参数，但 PeekMessage() 仅接受 PM_QS_xxx 常量。

这解释了 QueueStatus 指示的 WM_TIMER 消息数量与随后由 PeekMessage() 删除的消息数量之间的差异。您的 PeekMessage(PM_REMOVE) 调用不会删除 WM_TIMER 消息，而是完全删除其他内容。

我认为您误解了 PeekMessage() 的文档。 PM_QS_POSTMESSAGE 被记录为具有以下等价值：

((QS_POSTMESSAGE | QS_HOTKEY | QS_TIMER) << 16)

并且其他 PM_QS_xxx 常量被记录为等于相应的 QS_xxx 常量 < < 16，但没有任何地方表明情况始终如此，并且可以推断到所有 QS_xxxx 常量。

我怀疑 QS_TIMER << 16 正在产生一些过滤器，它的作用不仅仅是过滤 WM_TIMER 消息（显然是这样，我只是不能肯定地说它会产生什么过滤器）。

据我所知，WM_TIMER 是唯一与计时器相关的消息，因此不需要为更大的计时器消息超集设置更广泛的过滤器 - 没有这样的超集。如果您想过滤计时器消息，只需过滤WM_TIMER即可。