Spying while dragging the windows title bar

Let's suppose a click on a normal WS_OVERLAPPEDWINDOW window's title bar, followed by a few mouse drags and a button release.

Summary of messages obtained from Spy :

WM_SYSCOMMAND (SC_MOVE)

WM_MOUSEMOVE (*)

WM_CAPTURECHANGED

WM_ENTERSIZEMOVE

WM_MOUSEMOVE (*)

. . .

WM_MOUSEMOVE (*)

WM_LBUTTONUP (*)

WM_CAPTURECHANGED

WM_EXITSIZEMOVE

WM_SYSCOMMAND (return)

I'm trying to understand the messages with (*). They don't make sense to me since :

1) The mouse movement开发者_如何学Pythons and the button release are NOT in the window client area. Therefore, instead of WM_MOUSEMOVE and WM_LBUTTONUP, I should have WM_NCMOUSEMOVE and WM_NCLBUTTONUP.

2) If I put a break, on those messages (WM_MOUSEMOVE and WM_LBUTTONUP), in my window procedure, I don't intercept theses mesages while dragging the window's title bar !!!

1) The mouse movements and the button release are NOT in the window client area. Therefore, instead of WM_MOUSEMOVE and WM_LBUTTONUP, I should have WM_NCMOUSEMOVE and WM_NCLBUTTONUP.

I'm not sure about this one, but I can guess: maybe the system always sends WM_MOUSEMOVE, and this is converted to WM_NCMOUSEMOVE somewhere along the way (depending on the result of WM_NCHITTEST).

During a drag operation, your application doesn't get to see these messages anyway (as you noticed) so there's no point in doing the conversion.

2) If I put a break, on those messages (WM_MOUSEMOVE and WM_LBUTTONUP), in my window procedure, I don't intercept theses mesages while dragging the window's title bar !!!

Recall that WM_MOUSEMOVE and friends are posted, not sent. That means they will usually flow through your own message loop, and arrive at your window procedure via DispatchMessage.

When you start to drag a window, the application enters a so-called modal message loop. This loop will not return until the drag is finished, so until that time, your own message loop will not run! The WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE messages are sent to the window procedure when the modal loop is entered and exited, respectively.

Now, it could be that the modal loop also dispatches messages to your window procedure; but (at least for WM_MOUSEMOVE and such) it does not. And it shouldn't, because the modal loop itself is handling those messages -- passing them to the winproc would probably cause confusion.