Custom Mouse Capture Processing

[n!]

Hiya,
It seems to me that when a user depresses the mouse button, the
control acts as though it is internally calling the win32 function
SetCapture. As can be seen by clicking the mouse inside a client area and
dragging it outside, the window continues to receive mouse messages. Whilst
this is great for the majority of the time, I'd like to disable this
functionality as I'd like to manage this myself for certain controls in my
application.

I originally thought I could disable it by using SetStyle(
ControlStyles.UserMouse, true ) in my control initialization, but I appear
to be getting the same behaviour. Is there anyway I can achieve this? (this
is in C#, VS.NET2003, framework 1.1).

As an aside, could someone also clarify what setting UserMouse actually
does, as I haven't noticed any different behaviour so far?

Thanks,
n!

 

[Eric Cadwell]

Call ReleaseCapture!

protected override void WndProc(ref Message m)
{
int WM_MOUSEFIRST = 0x0200;

if (m.Msg == WM_MOUSEFIRST)
{
Point p = new Point((int)m.LParam);
if (!this.ClientRectangle.Contains(p))
Win32.ReleaseCapture();
}

base.WndProc (ref m);
}

HTH;
Eric Cadwell
http://www.origincontrols.com

 

[Eric Cadwell]

Win32.ReleaseCapture being defined as:

[DllImportAttribute ("user32.dll")]
public static extern bool ReleaseCapture();

 

[n!]

[DllImportAttribute ("user32.dll")]

public static extern bool ReleaseCapture();

hehe, yeh, that's the dirty answer I was hoping I could turn the
behaviour off. I think I will try that for now though, I didn't think of
that but that's probably because it'll feel so 'evil'

FWIW in my old C++ application (which I'm re-writing in C#) I used
DirectInput to support two extra capture modes, Wrapped (which allowed the
cursor to move off the screen and re-appear on the other side) and Hidden
(which removed the cursor from the display and had it reappear when capture
was completed). There was also standard, which used the normal capture mode
(via SetCapture).

Having it SetCapture and then immediately ReleaseCapture and then calling
DirectInput.Device.Acquire is gunna feel icky. But I'll give it a go,
thanks.

n!