鼠标静止不动时候的消息

优化程序的时候发现鼠标放在控件上不动也会不停的收到WM_MOUSEMOVE消息。

1，

于是想了各种办法寻找是哪儿触发的。

bp USER32!PostMessageW ".echo PostMessageW_Breakpoint_hit; g"

bp USER32!SendMessageW ".echo SendMessageW_Breakpoint_hit; g"

*Message没有抓到WM_MOUSEMOVE消息,却触发了该消息。

 

0:035> x USER32!*PostMessage*

76483baa USER32!PostMessageA = <no type information>

764812a5 USER32!PostMessageW = <no type information>

764904e3 USER32!PackAndPostMessage = <no type information>

76481285 USER32!NtUserPostMessage = <no type information>

 

0:035> x USER32!*SendMessage*

7648781f USER32!SendMessageTimeoutA = <no type information>

764e0030 USER32!_imp__WinStationSendMessageW = <no type information>

764797d2 USER32!SendMessageTimeoutW = <no type information>

7647d611 USER32!SendMessageToUI = <no type information>

764838ee USER32!InSendMessageEx = <no type information>

764da9a8 USER32!WinStationSendMessageW = <no type information>

764d886b USER32!NtUserQuerySendMessage = <no type information>

764797fc USER32!SendMessageTimeoutWorker = <no type information>

*Message* 全部bp一遍也没有抓到。

 

2，

用vs2005创建一个WIN32程序，只在WndProc里面加上WM_MOUSEMOVE的打印：

鼠标不动依然受到了WM_MOUSEMOVE消息,

 

3，

原来鼠标在窗口上不动也会收到这几个消息：

#define WM_GETICON 0x007F
#define WM_NCHITTEST 0x0084
#define WM_SETCURSOR 0x0020
#define WM_MOUSEMOVE 0x0200

-------------------------------------------------------------！

用spy++抓了一下，有的窗口能抓到有的不能抓到。

 

4，

看看MSDN怎么说

his message is posted to a window when user moves the mouse while pressing the left mouse button or moves the stylus while the tip is down. If another window does not capture the mouse stylus input, the OS posts the message to the window that contains the cursor or the stylus tip. If another window captures the mouse or stylus input, the OS posts the message to the window that has the capture.

Okay, so back to the original question, "Why do I get spurious WM_MOUSEMOVE messages?"

Notice that the delivery of a mouse message includes lots of work that is typically thought of as being part of mouse movement. Often, Windows wants to do that follow-on work even though the mouse hasn't actually moved. The most obvious example is when a window is shown, hidden or moved. When that happens, the mouse cursor may be over a window different from the window it was over previously (or in the case of a move, it may be over a different part of the same window). Windows needs to recalculate the mouse cursor (for example, the old window may have wanted an arrow but the new window wants a pointy finger), so it artificially sets the "The mouse moved, in case anybody cares" flag. This causes all the follow-on work to happen, a side-effect of which is the generation of a spurious WM_MOUSEMOVE message.