Thanks for your post.
Yes, the behavior you have seen is by design.
In Windows hardware input model, keyboard message will be dispatch from
RIT(raw input thread) to the thread connected to the RIT, then dispatch to
the focused window in this thread. However, mouse event will defaultly
dispatch from RIT to the window underlying the mouse cursor, NOT the window
in the thread has focus.
We can change this behavior by calling SetCapture API in windows, which
will force windows to dispatch the mouse message from RIT to the thread
calling SetCapture. However, windows will do this only if certain mouse
button is down. Once windows detect that when calling SetCapture, the mouse
button is not down, the messages will still be dispatch normally, that is:
to the window underlying the mouse cursor. In this situation, it seems that
we fail to capture the mouse. This is by design.
Now, for your scenario, I think you fail into the latter cause: you did not
push mouse button down, so the mouse message will not be dispatch to your
Currently, I am not sure of what problem you meet. If you want to get the
mouse drawing function without mouse button down, I think you can place a
flag, which indicate the drawing. In mouse move event, we can determine if
this flag is opened, if not, just do nothing, if it is opened, do the
actual drawing. Finally we can open/close this flag in mouse down event.
Does this meet your need? If you have any concern, please feel free to tell
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.