views:

159

answers:

3

Hi, I am using the following code to get mouse messages on the current process.

using (Process curProcess = Process.GetCurrentProcess())
using (ProcessModule curModule = curProcess.MainModule)
{
    return SetWindowsHookEx(WH_MOUSE_LL, proc, GetModuleHandle(curModule.ModuleName), 0);
}

For some reason when this code runs the mouse get slow for several seconds and then back to normal.

Any ideas?
Thanks

EDIT - hook method

private static IntPtr mouseEvent(int nCode, IntPtr wParam, IntPtr lParam)
{
    if (nCode >= 0 && MouseMessages.WM_LBUTTONDOWN == (MouseMessages)wParam)
    {
        MSLLHOOKSTRUCT hookStruct = (MSLLHOOKSTRUCT)Marshal.PtrToStructure(lParam, typeof(MSLLHOOKSTRUCT));     
        LastLeftClick = new ClickInfo { Time = DateTime.Now, X = hookStruct.pt.x, Y = hookStruct.pt.y };
    }
    return CallNextHookEx(hookID, nCode, wParam, lParam);
}

public class ClickInfo
{
    public int X { get; set; }
    public int Y { get; set; }
    public DateTime Time { get; set; }
}
A: 

What does your hook procedure look like?

If your process only has one UI thread, use a Message Filter instead: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.addmessagefilter.aspx

Tergiver
Why does it matter how does the procedure looks like if the problem is not in the mouse event process but on the registration itself?
Itay
Unless you are careful not to move the mouse at all during registration (is it invoked in response to a button click?), and you have a stable mouse (some mice, especially ball-less mice, are noisy), your hook procedure may be being invoked immediately.
Tergiver
I guess the hook is being invoked immediately but the slowdown is only on registration and not on other hook calls.
Itay
Right.. so what's your hook procedure doing? Is it making static calls which might invoke a static ctor the first time?
Tergiver
I added the hook method
Itay
A: 

I had the same problem (only it's c++ project, not c#) and resolved it by changing hook from WH_MOUSE_LL to WH_MOUSE (from low-level to normal level). For WM_LBUTTONUP and WM_RBUTTONUP messages it works ok.

The thing that amuses me is that code with WH_MOUSE_LL was doing fine at the time I wrote it (no mouse freezes etc.) It seems like some security update for Windows changed the behavior of the mouse hooks and previously fine code become a problem.

Bobrovsky
`WH_MOUSE` doesn't work for me at all :)
Itay
are you using DirectShow in your application? or maybe COM?
Bobrovsky
nope, i do not.
Itay
A: 

your hook proc is expensive; you just need to figure out why and how to fix it.

Even though though the code looks very minimal i suspect that there is some initial C# interop expense triggering the delays, perhaps due to JIT or paging.

if you change the code to do as much processing as possible off of this thread the problem should go away. as a C++ developer i even worry about the Marshal.PtrToStructure since low-level hooks are very sensitive and i can't say off the top of my head that this operation is guaranteed to be so cheap that it wouldn't impair mouse movement.

i've used low-level mouse hooks quite a bit in the past (in C++) and have never had problems unless the hook procedure itself is expensive. in C++ i try to avoid doing anything more than a PostMessage to an HWND that does the rest of the processing.

~jewels

Jewel S
IMHO if the hook was the problem I should be experiencing the problem on every hook call (which is basically the living time of my process). As for your first suggestion - do you know of any way to investigate this issue?
Itay
probably the best way to get to the root cause is to use a tool like 'xperf' to view what is happening on the system.this should give you direct insight into what's happening at the point where the mouse stalls.http://msdn.microsoft.com/en-us/performance/cc825801.aspxit is not the easiest tool in the world to use, but it's not that hard either, and it's free.
Jewel S