Q:

WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE - when using menu, not always paired

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 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"?

A:

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.

A:

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.

