When the system posts WM_MOUSEMOVE messages to a window using PostMessage(), it fills out a MSG struct with the message information as well as a timestamp and the current cursor position (in screen corodinates). The WM_MOUSEMOVE message itself contains the
new cursor position mapped to the client area of the target window.
Let's say an application has a control that, when clicked, captures the mouse and on every mouse move resizes the window. Let's also say that the user moves the mouse very fast and two WM_MOUSEMOVE messages are created right after each other and posted to
It might look like this in raw message format:
<01882> 002402E2 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1 yPos:10 [wParam:00000001 lParam:00A20001 point:(60, 187)]
<01883> 002402E2 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:2 yPos:10 [wParam:00000001 lParam:00A20000 point:(61, 187)]
The application then handles the first message, looks at the cursor position in the message (which is mapped to the client area) and indicates that the mouse was moved 1 pixel horizontally into the client area. The window is then resized accordingly.
The second message is then handled, but hey, wait a second, the client cursor position, which when posted indicated it was moved 2 pixels horizontally into the client area, is no longer valid because those two pixels were calculated at the time the message
was posted and the window has been moved since then. That is, instead of moving the window two pixels to the right, it should only be moved 1.
My question then is: How does Windows account for this? Does it look at the message cursor position, i.e. the position that the system stamped in the MSG struct when the message was posted, and figure things out?
If so, is there a way to override the message cursor position?