如何查找谁生成了 Windows 消息
我们有一个非常大、复杂的 MFC 应用程序。 由于某种原因，运行应用程序的特定模式正在向窗口生成 WM_SIZE 消息。它不应该发生，并且正在扼杀性能。 我可以看到消息正在被处理。 如何找到代码中生成窗口消息的内容或位置？
注意：当我们将性能监控工具挂接到应用程序中时，这种情况往往会发生。所以可能是第三方工具在做这件事。
但它只发生在这种特定的操作模式中，因此它可能是某种奇怪的交互。
We have a very large, complex MFC application.
For some reason a particular mode for running our application is generating WM_SIZE messages to the window. It should not be happening and is killing performance.
I can see the message getting handled. How can I find what or where in the code, is generating the window message?
Note: it tends to happen when we have a performance monitoring tool hooked into the application. So it might be the third party tool doing it.
But it only happens in this one particular mode of operation so it might be some sort of strange interaction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以看到消息映射来指定所有窗口的 onSize 已被映射。
作为“不优雅”的替代方案，您可以在 PreTranslateMessage 中捕获 WM_ONSIZE 并使用 PreTranslateMessage 中传递的 pMsg 结构的 hwnd 成员查看窗口句柄。
You could see message map to specify for which all windows onSize has been mapped.
as an 'not elegant' alternative, you could trape WM_ONSIZE in PreTranslateMessage and see windows handle using hwnd member of pMsg structure being passed in PreTranslateMessage.
知道谁发送了消息有什么帮助？我宁愿关注解决方案，例如当检测到大量此类消息时延迟处理消息（假设此处理负责性能命中）。
例如，如果您在 x 毫秒内收到太多消息，您可以决定启动一个计时器，并在计时器到期时仅处理收到的最后一条消息。这样，您每 x 毫秒最多处理一条消息，而不是每条消息。
How would it help to know who sends the message? I would rather focus on a solution, such as delay processing of the message (assuming this processing is responsible for the perf hit) when an avalanche of such messages is detected.
e.g. If you receive too many messages within x milliseconds, you may decide to start a timer and process only the last message receives when the timer elapses. This way, you process max one message per x milli-seconds instead of each one.