Reply to thread

Message: [QUOTE="Jeffrey Tan[MSFT], post: 6090655"] Hi Schemer, 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 window. 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 me, Thanks ================================================================== 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 of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - [URL="http://www.microsoft.com/security"]www.microsoft.com/security[/URL] This posting is provided "as is" with no warranties and confers no rights. [/QUOTE]

Verification