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:
- open the window menu
- click on Size
- do not resize the window, rather click into the window
Notice the window开发者_StackOverflow社区 never received any WM_EXITSIZEMOVE
.
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"?
I know this is rather late, but it might still help you - and it is likely to help others who find it in a search, like I did.
It seems that in the situation you mentioned, the WM_CAPTURECHANGED message is sent when the resizing is "cancelled". After extensive testing it seems that this is always sent just before WM_EXITSIZEMOVE is (or should be!), and at no other stage between WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE.
The WM_CAPTURECHANGED message is sent at various other times too, so you should only react to it if a WM_ENTERSIZEMOVE message has been sent, but the following WM_EXITSIZEMOVE hasn't.
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.
You should get the WM_SIZE message every time a sizing operation is finished. And while sizing, you'll get WM_SIZING messages.
Maybe you could use those too to unpause your app?
精彩评论