WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE - 使用菜单时，不总是配对 [英] WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE - when using menu, not always paired

问题描述

为了防止我的应用程序在用户移动窗口时更改窗口内容，我捕获了 WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE 并且我在消息之间暂停应用程序。但是，有时我会收到 WM_ENTERSIZEMOVE ，但没有 WM_EXITSIZEMOVE 。一个重现是：

To prevent my application changing the window content while user is moving its window around, I capture messages WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE and I pause the application between the messages. However, sometimes it happens I receive WM_ENTERSIZEMOVE but no WM_EXITSIZEMOVE at all. One repro is:

• 打开窗口菜单


• 点击大小


• 不调整窗口大小，而是点击进入窗口

注意窗口从未收到任何 WM_EXITSIZEMOVE 。

Notice the window never received any WM_EXITSIZEMOVE.

当检查这是如何工作，我也检查了Microsoft DirectX示例，我注意到同样的问题。一旦你按照上面的重现步骤，示例应用程序看起来冻结（我已经试过它的BasicHLSL示例从2009年3月SDK）。

When checking how this works, I have also checked Microsoft DirectX sample and I have noticed the same problem. Once you follow the repro steps above, the sample application looks frozen (I have tried it just now with BasicHLSL sample from March 2009 SDK).

应用程序如何预期回应这个？是否还有其他条件会终止移动或调整模态循环

How is the application expected to respond to this? Are there some other conditions which should terminate the "moving or sizing modal loop"?

推荐答案

临时解决方法，我现在取消暂停应用程序，每当我收到WM_ACTIVATE消息。这似乎有一个解决这种特殊情况（你可以恢复应用程序通过再次激活），似乎没有破坏任何东西。

As a temporary workaround, I now un-pause the application whenever I receive WM_ACTIVATE message. This seems to have a kind solved this particular case (you can recover the application by activating it again) and did not seem to break anything.

这样的解决方案闻到我，虽然。我宁愿了解它应该如何工作，而只是依靠有限的测试。

Such solution smells to me, though. I would rather understand how it should work rather then relying on a limited testing only.

这篇关于WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE - 使用菜单时，不总是配对的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！