我要创建一个程序，安装一个键盘钩子捕获所有按键和显示一些文字与他们无关。

不过，我在一个障碍命中，这是安装钩子，当某些键改变人们的行为。

我会看到张贴的小，但完整的，测试程序，但现在我只是描述问题。

这个问题表现出自己的Windows 7 64位，在.NET 4.0中，C＃程序。我想这一切都不重要。

我的钩通过 SetWindowsHookEx函数自行安装，然后处理系统处理的所有键。

如果挂钩的方法只是返回，或不关键的最小处理（我会发布什么样的变化的行为在第二个），键盘按预期的计划。

不过，如果我调用这个函数， toascii将从User32.dll中，找出哪些关键在我的键盘OemTilde或类似的真的是，那么任何键覆盖下一个关键停止工作。我不知道正确的名称，这样的键，但两个撇号类型，`和，以及〜和¨，停止运行。

举例来说，如果我打〜然后 N ，它会显示如下：

在没有键盘钩子安装：ñ 使用键盘钩子安装：N（注意没有了〜以上）

有谁知道为什么会这样，我怎么能解决这个问题？

现在我会满足于仅仅正确处理的按键在其他程序中，即使这意味着我将不能正确地检测正确的按键顺序在我自己的程序。

一些详细信息：

如果我称之为 toascii将函数作为钩子方法的一部分，那么会出现不同的问题。像钥匙¨处理两次，即得。如果我打了¨键，记事本就会收到两份¨¨字符，并创下 N 现在只是增加了 N 。

不过，如果我使用的BeginInvoke 来处理一个单独的线程的关键，从键盘钩子方法返回后，出现了第一个问题。

我的程序可能是一个有点特殊在于：

我不使用键盘的状态（即，在国家重点256-byte数组我绕过只是充满了0） 在我不在乎死键（在我的程序将无法处理它们的意义，我只是在乎足够的了解他们，我不希望我的程序，使它们没用到系统的其他部分）

因此​​，我的code结束了寻找如下：

 私人布尔IsDeadKey（UINT键）
{
    返回（（Hook.Interop.MapVirtualKey（键，2）及2147483648）== 2147483648）;
}

无效_Hook_KeyDown_Async（KeyDownEventArgs E）
{
    VAR inBuffer =新的字节[2];
    字符键='\ 0';
    如果（！IsDeadKey（（UINT）e.Key code））
    {
        INT ASCII = Hook.Interop.ToAscii（（int）的e.Key code，
                                            e.Scan code，
                                            _KeyState，
                                            inBuffer，
                                            e.Flags）;
        如果（ASCII == 1）
        {
            键= Char.ToUpper（（炭）inBuffer [0]）;
        }
    }

    的BeginInvoke（
        新的动作＆LT;键，布尔，布尔，布尔，字符＆GT;（ProcessKeyboardEvent）
        e.Key code，e.Control，e.Shift，e.Alt，关键）;
}
 

解决方案

这些键被称为的 死键 的，你可能能够通过删除调用 toascii将来解决这个问题。另请参阅以下相关主题：

  

ToAscii/ToUni$c$c在一个键盘钩子摧毁死键。

更新：我还没有看到你的code，但处理的 KeyboardProc 的回调函数，你能确认你通过键盘消息的 code 参数小于0？该文件说：

  

code 的[在] INT

     

c中的钩子程序A $ C $使用，以确定如何处理消息。 如果的 code 的小于零，钩子程序必须将消息传递给 CallNextHookEx方法功能，无需进一步的处理，并且应该返回通过 CallNextHookEx方法返回的值。

没有为样本建立一个管理挂钩 MSDN中：

 如果（N code＆LT; 0）
{
    返回CallNextHookEx方法（HHOOK，N code，的wParam，lParam的）;
}
其他
{
    //处理你的讯息

    返回CallNextHookEx方法（HHOOK，N code，的wParam，lParam的）;
}
 

I'm creating a program that installs a keyboard hook to capture all keys and display some text related to them.

However, I've hit upon a snag, and that is some keys change behavior when the hook is installed.

I'll see about posting a small, but complete, test program, but for now I'll just describe the problem.

The problem exhibits itself on Windows 7 64-bit, in .NET 4.0, a C# program. I assume none of this matters.

My hook installs itself via SetWindowsHookEx and then handles all keys processed in the system.

If the hook method simply returns, or does minimal processing of the key (I'll post what changes the behavior in a second), the keyboard functions as expected in programs.

However, if I call this function, ToAscii from User32.dll, to figure out which key on my keyboard OemTilde or similar really is, then any key that "overlays the next key" stops functioning. I don't know the correct name for such keys, but the two apostrophe-types, ` and ´, as well as ~ and ¨, stops functioning.

For instance, if I hit ~ and then N, it displays as follows:

Without keyboard hook installed: ñ With keyboard hook installed: n (notice no ~ above)

Does anyone know why this happens and how I can fix this problem?

For now I'll settle for just handling the keys correctly in other programs, even if that means that I won't be able to correctly detect the right key sequences in my own program.

Some more information:

If I call the ToAscii function as part of the hook method, then a different problem occurs. Keys like ¨ are processed twice, ie. if I hit the ¨ once, Notepad receives two ¨¨ characters, and hitting N now just adds the N.

However, if I use BeginInvoke to process the key on a separate thread, after returning from the keyboard hook method, the first problem occurs.

My program is probably a bit special in that:

I don't use keyboard state (ie. the "Key state" 256-byte array I pass around is just full of 0's) I don't care about dead keys (in the sense that my program won't process them, I care just enough about them that I don't want my program to render them useless to the rest of the system)

As such, my code ended up looking as follows:

private bool IsDeadKey(uint key)
{
    return ((Hook.Interop.MapVirtualKey(key, 2) & 2147483648) == 2147483648);
}

void _Hook_KeyDown_Async(KeyDownEventArgs e)
{
    var inBuffer = new byte[2];
    char key = '\0';
    if (!IsDeadKey((uint)e.KeyCode))
    {
        int ascii = Hook.Interop.ToAscii((int) e.KeyCode,
                                            e.ScanCode,
                                            _KeyState,
                                            inBuffer,
                                            e.Flags);
        if (ascii == 1)
        {
            key = Char.ToUpper((char) inBuffer[0]);
        }
    }

    BeginInvoke(
        new Action<Keys, Boolean, Boolean, Boolean, Char>(ProcessKeyboardEvent),
        e.KeyCode, e.Control, e.Shift, e.Alt, key);
}

解决方案

These keys are called dead keys and you might be able to solve the problem by removing the call to ToAscii. See also the following related thread:

ToAscii/ToUnicode in a keyboard hook destroys dead keys.

Update: I haven't seen your code, but when processing the parameters of the KeyboardProc callback function, can you check that you pass the keyboard message on when the code parameter is less than 0? The documentation says:

code [in] int

A code the hook procedure uses to determine how to process the message. If code is less than zero, the hook procedure must pass the message to the CallNextHookEx function without further processing and should return the value returned by CallNextHookEx.

There is a sample for setting up a managed hook in MSDN:

if (nCode < 0)
{
    return CallNextHookEx(hHook, nCode, wParam, lParam);
}
else
{
    // process message here

    return CallNextHookEx(hHook, nCode, wParam, lParam); 
}