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

Re: MouseDown causes MouseLeave NOT to be fired. by discussion

discussion
Wed Nov 26 07:23:06 CST 2003

To repro.

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

BUG BUG BUG :P


<discussion@discussion.microsoft.com> wrote in message
news:eF2n69BtDHA.2392@TK2MSFTNGP10.phx.gbl...
> 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
>
>



Re: MouseDown causes MouseLeave NOT to be fired. by Phil

Phil
Wed Nov 26 08:04:03 CST 2003

<discussion@discussion.microsoft.com> wrote in message
news:uRRt$%23BtDHA.2932@TK2MSFTNGP11.phx.gbl...
> To repro.
>
> Keep the mouse down and drag out of control, no mouse leave event ever.
>
> BUG BUG BUG :P

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.



Re: MouseDown causes MouseLeave NOT to be fired. by discussion

discussion
Wed Nov 26 08:37:55 CST 2003

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


"Phil Da Lick!" <phil_the_lick@nospam.hotmail.com> wrote in message
news:esAU3ZCtDHA.3416@tk2msftngp13.phx.gbl...
> <discussion@discussion.microsoft.com> wrote in message
> news:uRRt$%23BtDHA.2932@TK2MSFTNGP11.phx.gbl...
> > To repro.
> >
> > Keep the mouse down and drag out of control, no mouse leave event
ever.
> >
> > BUG BUG BUG :P
>
> 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.
>
>



Re: MouseDown causes MouseLeave NOT to be fired. by discussion

discussion
Wed Nov 26 08:40:26 CST 2003

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.



"Phil Da Lick!" <phil_the_lick@nospam.hotmail.com> wrote in message
news:esAU3ZCtDHA.3416@tk2msftngp13.phx.gbl...
> <discussion@discussion.microsoft.com> wrote in message
> news:uRRt$%23BtDHA.2932@TK2MSFTNGP11.phx.gbl...
> > To repro.
> >
> > Keep the mouse down and drag out of control, no mouse leave event
ever.
> >
> > BUG BUG BUG :P
>
> 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.
>
>



Re: MouseDown causes MouseLeave NOT to be fired. by discussion

discussion
Wed Nov 26 09:00:13 CST 2003

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.


<discussion@discussion.microsoft.com> wrote in message
news:uDvjNqCtDHA.1744@TK2MSFTNGP12.phx.gbl...
> 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.
>
>
>
> "Phil Da Lick!" <phil_the_lick@nospam.hotmail.com> wrote in message
> news:esAU3ZCtDHA.3416@tk2msftngp13.phx.gbl...
> > <discussion@discussion.microsoft.com> wrote in message
> > news:uRRt$%23BtDHA.2932@TK2MSFTNGP11.phx.gbl...
> > > To repro.
> > >
> > > Keep the mouse down and drag out of control, no mouse leave event
> ever.
> > >
> > > BUG BUG BUG :P
> >
> > 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.
> >
> >
>
>



Re: MouseDown causes MouseLeave NOT to be fired. by Phil

Phil
Wed Nov 26 09:30:50 CST 2003

<discussion@discussion.microsoft.com> wrote in message
news:eNlRR1CtDHA.1680@TK2MSFTNGP12.phx.gbl...
> 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.

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
};



Re: MouseDown causes MouseLeave NOT to be fired. by 100

100
Wed Nov 26 10:00:37 CST 2003

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!" <phil_the_lick@nospam.hotmail.com> wrote in message
news:OpvlWKDtDHA.1224@TK2MSFTNGP09.phx.gbl...
> <discussion@discussion.microsoft.com> wrote in message
> news:eNlRR1CtDHA.1680@TK2MSFTNGP12.phx.gbl...
> > 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.
>
> 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
> };
>
>



Re: MouseDown causes MouseLeave NOT to be fired. by Phil

Phil
Wed Nov 26 10:39:38 CST 2003

"100" <100@100.com> wrote in message
news:%23ElhnaDtDHA.1088@tk2msftngp13.phx.gbl...

> 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

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.



Re: MouseDown causes MouseLeave NOT to be fired. by 100

100
Wed Nov 26 10:54:12 CST 2003

Hi Phil,
> > 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
>
> 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.

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