tags:

views:

33

answers:

1

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 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.

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 !!!

A: 

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.

Thomas
It is my understanding that Spy shows the messages sent or dispatched to the window's procedure.
jaayrosa
It probably also shows the messages posted to the application's message queue, using the `WH_GETMESSAGE` hook. That might be how it sees those messages, while your winproc doesn't.
Thomas
Are you sure about this last comment ? Could you give any MSDN's docs where this subject is discussed.
jaayrosa
I'm not sure, because I don't have the Spy++ source, and I can't find any documentation on how it works. It's just the most obvious way to do it, I guess.
Thomas
Let me check if I got your point straight : you're saying that, in between the WM_ENTERSISEMOVe and the WM_EXITSIZEMOVE messages, my window procedure just receives the messages sent to it, but not the posted ones, which are handled in a different message loop, although Spy lists those messages, as if they were dispatched to my window procedure. Maybe you are right, but it seems to me a very convoluted explanation !
jaayrosa
Could be; it was past my bedtime when I wrote this. I maybe tried to explain more than I should have, because I did not know how much you knew about the interplay between messages, message loops and window procedures. Anyway, it seems you get my drift now, and even if my answer was not 100% correct it may have given you something to look into.
Thomas
My guess is that those messages (WM_MOUSEMOVE and WM_LBUTTONUP) should not be listed by Spy. It's just a bug in the program !I'm giving you the credit for the answer. Thanks.
jaayrosa