窗口移动和调整大小会干扰 MsgWaitForMultipleObjects
我有一个应用程序，它使用 MsgWaitForMultipleObjects 进行消息循环，以在泵送 ui 消息时捕获其他事件。似乎只要窗口被移动或调整大小，DefWindowProc 就会开始它自己的消息循环，直到释放鼠标。这种情况会阻止外部循环同时捕获其他消息。
正因为如此，我不想对应用程序进行多线程处理。还有其他方法可以解决吗？
I have an application that message-loops using MsgWaitForMultipleObjects to catch additional events while pumping ui messages. It seems that as soon as a window is being moved or resized, DefWindowProc begins it's own message loop until the mouse is being released. This situation prevents from the outer loop to catch the additional messages in the meantime.
I'd hate to multi-thread the application just because of this. Is there any other way to solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MsgWaitForMultipleObjects 在传统的多线程程序中几乎没有用处。它在游戏中有一些用途 - 传统的非客户端框架元素被省略，并且避免了诸如“MessageBox”和“DoDragDrop”之类的 API...
通常它在不托管可见窗口的“UI 工作”线程中找到了最佳用途，但使用消息队列作为线程间消息传递系统，并且还需要等待内核句柄。
就您而言，创建第二个线程似乎是不可避免的。讽刺的是，PostThreadMessage + MsgWaitForMultipleObjects 可能是在 GUI 线程和“ui”工作线程之间建立可靠通信机制的最简单方法。
MsgWaitForMultipleObjects has very few uses in a traditional multi threaded program. It has some use in Games - where traditional non client frame elements are omitted and APIs like "MessageBox" and "DoDragDrop" are avoided...
Usually it finds its best use in "UI worker" threads that don't host visible windows, but use the message queue as an inter thread messaging system and also need to wait on kernel handles.
In your case, making a second thread does not seem avoidable. Ironically, PostThreadMessage + MsgWaitForMultipleObjects will probably be the easiest way to set up a reliable communication mechanism between the GUI thread and your "ui" worker thread.
Windows API 中还有几个其他位置将进入它们自己的消息循环。如果您需要在这些时间内继续处理消息，那么您将需要一个单独的线程。
There are several additional places in the Windows API that will enter their own message loop. If you need to continue handling your messages during these times then you'll need a separate thread.