4

windows 如何准确地决定 SendMessage 应该返回 - 也就是说，它如何决定接收线程已完成对发送的消息的处理？

详细场景：我让线程 A 使用 SendMessage 向线程 B 发送一个线程。显然，直到线程 B 处理完消息，SendMessage 才会返回。线程B弹出一个对话框，开始抽消息。在我的场景中，队列上有一条 WM_KILLFOCUS 消息，由线程 B 抽取。结果是线程 B 上的 WM_COMMAND 消息。线程 B 将此 WM_COMMAND 消息传递给默认窗口 proc。当它这样做时，SendMessage 返回到线程 A，即使原始消息还没有完成处理！到底是怎么回事？看起来默认窗口进程以某种方式混淆了窗口，使其认为原始发送的消息已完成。

那么有没有已知的场景，其中泵送消息和调用默认窗口 proc 可以欺骗 SendMessage 返回？

谢谢！菲尔

4

4 回答 4

4

只要消息的处理已经开始，处理线程间消息的 WindowProc 就可以调用ReplyMessage以允许调用线程在处理继续时继续。

于 2009-12-10T20:49:15.603 回答
2

由于SendMessage有返回值，它总是在消息被处理之后。

PostMessage另一方面不会等待消息被处理。

从SendMessage上的 MSDN ：

SendMessage 函数调用指定窗口的窗口过程，直到窗口过程处理完消息才返回。

在处理消息之前它不会返回。

于 2009-12-10T16:54:35.187 回答
1

从 MSDN 中，听起来问题可能是在线程 B 中显示对话框可能会导致死锁。请参阅消息死锁。

可能是因为线程 A 收到的消息是非排队消息。来自 MSDN：

但是，发送线程将在等待其消息被处理时处理传入的非排队消息。为防止这种情况，请使用设置了 SMTO_BLOCK 的 SendMessageTimeout。有关非排队消息的更多信息，请参阅非排队消息。

于 2009-12-10T17:08:15.107 回答
0

听起来好像您的原始 SendMessage 没有返回，而是在处理发送的消息期间调用了线程 A 中的 WindowProc。没有要求消息处理程序必须避免调用 SendMessage 以响应收到消息。

您应该能够在您的调用堆栈中看到对 SendMessage 的原始调用，此时您收到了您为响应焦点更改消息而发送的 WM_COMMAND。

于 2009-12-10T17:05:22.620 回答