BUG : MouseDown causes MouseLeave NOT to be fired.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I noticed that when I have a mousedown event i never ever get a mouse
leave event even when i DO leave the control.

Is this a bug? Shouldnt i get a mouseleave event when i leave that
control? Even if mouse is down.

I think i should


Thanks
 
To repro.

Keep the mouse down and drag out of control, no mouse leave event ever.

BUG BUG BUG :P
 
To repro.

Keep the mouse down and drag out of control, no mouse leave event ever.

BUG BUG BUG :P
Click to expand...

I dont think so. Not knowing the framework at all, I'n guessing that this is
caused by the framework capturing the mouse during mouse down. If the mouse
is captured, you wont get a mouse leave at all, as the system fires
wm_mousemove messages at the window even if the cursor is outside the client
area.
 
I would like to be able to detect I have left the actual control with the
mouse button down. I should be able to as this is limiting, causing
negative mousemove coordinates etc etc...

Its a bug in my book, ie., bad design of messages
 
I do. For example, say I have a mouse down, and changed the cursor, I move
outside with teh mouse still down, how can I know when to change the cursor
again to indicate its OUTSIDE the region of my control.

With the current messging model I cannot. I would need to get a MouseLeave
event even with MouseDown to detect that.
 
Workaround for MS's lack of MouseLeave event is to detrect the MouseMove
coordinates and if they are larger than the control or negative, fire the
MouseLeave event youreself if MS dont do it.

Will this be fired in later versions because I dont like having cludge code
in there to workaround lack of features.
 
Workaround for MS's lack of MouseLeave event is to detrect the MouseMove
coordinates and if they are larger than the control or negative, fire the
MouseLeave event youreself if MS dont do it.

Will this be fired in later versions because I dont like having cludge code
in there to workaround lack of features.
Click to expand...

No it wont be fixed because it is not a bug. This is just the way windows
works unfortunately. It is common practice for the window to capture the
cursor while the button is pressed. If you *really* need to determine where
the cursor is try [this is a raw api version, you will need to convert to
the .net equiv]

POINT pt;

GetCursorPos(&pt);
if(GetWindowFromPoint(pt)==hWnd)
{
// we're in out window
}
else
{
// we're not in our window
};
 
Hi,
No, this is not a bug. Phil is right that is because the framework sets the
capture whenever the mouse left button is pressed down. And I believe this
is good because in 99% of the casses we want to set the capture(normaly it
is used for dragging).
What is bad is that the capture is released when a button is released. It
doesn't matter which one. It could be the left or the right or even maybe
the middle one (the case with the middle one I have not tested). So a
problem may arise if the user presses the left button, start draging
(everything is fine so far) then presses the right mouse button and
released the right one. At this point the capture is lost. Which is bad
because I don't really care of the right mouse button and react only on the
left one. So I have to handle releasing any button and if it is not the left
one just cancel the operation.

But your problem has a cure. In the MouseDown event just set the Capture
property of your control to *false* and you will get rid of the capture and
will receive the MouseLeave event when the mouse leaves the control and
won't receive any mouse events afterwards.

HTH
B\rgds
100

Phil Da Lick! said:
Workaround for MS's lack of MouseLeave event is to detrect the MouseMove
coordinates and if they are larger than the control or negative, fire the
MouseLeave event youreself if MS dont do it.

Will this be fired in later versions because I dont like having cludge code
in there to workaround lack of features.
Click to expand...

No it wont be fixed because it is not a bug. This is just the way windows
works unfortunately. It is common practice for the window to capture the
cursor while the button is pressed. If you *really* need to determine where
the cursor is try [this is a raw api version, you will need to convert to
the .net equiv]

POINT pt;

GetCursorPos(&pt);
if(GetWindowFromPoint(pt)==hWnd)
{
// we're in out window
}
else
{
// we're not in our window
};
Click to expand...
 
What is bad is that the capture is released when a button is released. It
doesn't matter which one. It could be the left or the right or even maybe
the middle one (the case with the middle one I have not tested). So a
problem may arise if the user presses the left button, start draging
(everything is fine so far) then presses the right mouse button and
released the right one. At this point the capture is lost. Which is bad
Click to expand...

Seriously? Man, that is bad. What's the thinking behind that? I can't think
of a single situation where this would be useful, but plenty of situations
where it'd be a major pain.
 
Hi Phil,
Seriously? Man, that is bad. What's the thinking behind that? I can't think
of a single situation where this would be useful, but plenty of situations
where it'd be a major pain.
Click to expand...

Yep, so far I have nothing but problems with that. It is good that Charles
Petzold's book "Programing MS Windows with c#" brought my attention on
that. I haven't tried if API SetCapture has something to do with this
strange behaviour. I don't believe it so; otherwise I must have noticed it
before.

B\rgds
100
 
Back
Top