Capturing mouse, key events

[Schemer]

Hello,

I'm trying to modify a C# sample app (Scribble) such that the user can draw
w/o holding the mouse button down -- first mouse click
turns on drawing, moving the mouse draws, and the second mouse click turns
it off.
In the MouseUpHandler, I set the Capture property:
this.Capture = true;

Some TRACE output in the MouseMove handler shows that when the cursor leaves
the mdi child window, it stops getting the mouse messages. Also, after
setting Capture to true in the mouseup handler (after calling
base.OnMouseUp()), Capture is _false_
in the mousemove handler.

While I'm just experimenting with this app, eventually I'll be drawing
rubber band shapes and I need to have the rubber band drawing track with the
mouse, even when it is outside the client window. Is there a way to
accomplish this?

Also, when a window has 'captured' the mouse, should it get all the keyboard
input as well, or does something else need to be done? For example, in a
differnt app, when I am drawing a rubber rectangle with the mouse button
held down, my shortcut key to bring up the Open File dialog still works.

TIA for any ideas.

 

[Nassos]

Hi Schemer,
For the mouse capturing, my implementation is a less clever one, i use the
mouseDown event and set a global variable DoDraw to : DoDraw = !DoDraw; and
first click i draw second i stop drawing, and don't have the out of bound
problem.
For the Second question, my first thought is, use the MouseLeave event of
the control you are drawing when the event fires (the mouse left the
control) inflate the Control Regtangle by the difference between the end of
the control and the mouse potition (For that use the static method
MousePosition) and continue to draw.
Hope that helps,
If you want clarification i will be happy to help

 

[Schemer]

I don't understand how your global var affects the mousemove messages,
though. I have the drawing behavior I want (using something like your
flag), but when the cursor is outside of the rect, the window doesn't get
the mousemove messages.
Perhaps you misunderstood: My first mousedown/mouseup pair turns on
drawing; drawing occurs when the mouse is moved, and drawing is turned off
with the second mousedown/mouseup pair. I want the drawing to occur with no
button held down.

Thanks for the reply.

 

[Nassos]

Schemer,
that's the reason that I write to you to use the MouseLeave event so when
outside the drawing area the event will fire and since you know you are
outside then make the drawing area bigger scroll it and change the
MousePosition to be inside the drawing area (So the cursor will appears
never to leave the Drawing surface), so consequently the mouse will be
inside and the MouseMove event will fire again.

Hope that helps

 

[Jeffrey Tan[MSFT]]

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! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

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

It seems I'm not explaining this problem clearly.

Some pseudocode:

DrawMode = false;

OnMouseDown {
base.OnMouseDown();
}

OnMouseUp {
base.OnMouseUp();
DrawMode = !DrawMode;
this.Capture = true;
}

OnMouseMove {
If DrawMode == true
/* do drawing stuff */
}

This works as expected when the cursor is in the window the mousebutton was
clicked in.
When the cursor is outside of the window, the window does not receive the
MouseMove messages. If it doesn't recieve the MouseMove messages, the flag
is irrelevant.

Note that even when the cursor is w/i the drawing window, Capture != true in
the MouseMove handler. Why is that?

Nassos' suggestion to catch the MouseLeave event makes sense, to a point.
It seems like a very expensive solution, though, changing the drawing
window's rectangle on every MouseMove/MouseLeave.

Thanks for the response.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Currently, I am doing some research on this issue, I will reply ASAP,
thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Does my reply make sense to you? Is your problem resolved? Please feel free
to tell me, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

If you are referring to your post of 7/12/2005, it makes sense, but it does
not address my problem at all.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Thanks for your feedback.

Currently, I am not sure what is your real concern. Yes, I have read your
message in 7.12, in that message, you provided the code snippet to show me
your problem is:
1. Why Capture=true in mouseup event does not persist the capture state.
2. When mouse moves out of the window client area, no mouse move message is
sent to the application, so no mouse_move event is fired.

I am not sure if you have got my reply in 7.14, in that message, I think I
have added some comment for your 2 concerns:
1. WInform code released the capture internally after mouseup event
2. We can use Journal Record hook to force entire system mouse messages to
be sent to our application.

I also have attached a sample project to demonstrate #2 way. Do you have
any further concern on my 7,.14 reply? Please feel free to tell me, I will
follow up with you. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

Thanks for following up, Jeffrey.
Somehow, I never received your reply of 7/14. Did you post it here, or send
it to me directly?
Thanks.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Have you got my further reply? Is your problem resolved? Please feel free
to tell me, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

I haven't received anything....

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

It seems that you can not get my message when there is an attachment in it.
Currently, I suggest you provide a email address for me, then I can email
the sample project to you directly. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

Remove the spaces and make the obvious corrections:
c b n e 2 0 0 1 at hotmail dot com.
Thanks Jeffrey.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Thanks for your feedback.

I have sent the reply content and the sample project to you with email. If
you have any further concern, please feedback here. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

Got it, thank you.

 

[Jeffrey Tan[MSFT]]

You are welcome. If you have any further concern, please feel free to
feedback. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Schemer,

Does my sample makes sense to you? If you have any concern, please feel
free to tell me, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Schemer]

Yes, thank you.

We also discovered that handling the WM_LBUTTONUP in an overridden WndProc()
works.