Question

I have a custom control that updates two NumericUpDowns with the current mouse coordinates by handling the MouseMove event.

However I have experienced a strange case where the MouseMove event is fired even when this should not happen (I have turned off my wireless mouse and disabled the trackpad). So, MouseMove happens even if the mouse does not move.

I've made a simple check and verified that between these "ghost" MouseMove events the position of the mouse pointer does not change. I exploited this to my advantage to make sure that the method handling the event is only called when the pointer has actually moved, so I have been able to meet the requirements for my application.

However, I am still puzzled, as I don't understand what could fire MouseMove events when all mice/trackpads are disabled. Looking at the call stack in Visual Studio, it seems to me that the firing of the MouseMove event is "genuine", as if the mouse really moved, not as if it was fired by some other part of the application (e.g. to simulate a MouseMove).

Any suggestions on what might be the reason for this? Thank you!

EDIT: Following King King's suggestion, I modified the code to print a string every time the message for MouseMove is detected. I've noticed that when the mouse is off and the pointer is hovering the control, the string is printed when I Alt-Tab to switch between application. Perhaps this has something to do with the application being redrawn?

Was it helpful?

Solution

Windows synthesizes a fake WM_MOUSEMOVE message sometimes. This in particular will happen on a focus change from one window to another. The window that gets the focus also gets the move message. Seeing this happen when you use Alt+Tab is an excellent lead that this is indeed the source of the message.

This is all entirely intentional. It ensures that the other train of messages triggered by WM_MOUSEMOVE will occur. In particular WM_NCHITTEST and WM_SETCURSOR. So that the correct mouse cursor shape is displayed. Otherwise affected in Winforms by the Control.Cursor and Application.UseWaitCursor properties.

You'll have to live with this, do make sure that this is never a problem.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top