【问题标题】:Global low level keyboard hook not preventing OEM keys全局低级键盘挂钩不会阻止 OEM 键
【发布时间】:2012-08-15 11:00:15
【问题描述】:

我写了如下方法,防止所有键被按下:

private IntPtr HookHandler(int nCode, IntPtr wParam, ref KBDLLHOOKSTRUCT lParam)
{
    if (nCode >= 0)
    {
        ...

        //Return a nonzero value to prevent the system from passing the message to the
        //rest of the hook chain or the target window procedure.
        return (IntPtr)1;
    }

    return NativeMethods.CallNextHookEx(_hookID, nCode, wParam, ref lParam);
}

但是,当上面的代码运行时,它允许我的键盘的 calc 键或电子邮件键等键。

我进行了调试,代码确实到达了return (IntPtr)1; 行(并且它确实正确显示了正在按下的键),但是到那时,计算窗口(或其他)已经打开了。即使我返回 1,也为时已晚。

我可以在这里做些不同的事情吗?

【问题讨论】:

    标签: c# .net winapi keyboard-hook


    【解决方案1】:

    嗯,应该可以的。正常路由是从 WM_KEYDOWN 消息到默认窗口过程生成的 WM_APPCOMMAND 消息。 WM_XBUTTONUP 是另一条路线,但不太可能。使用 Spy++ 查看是否有任何异常情况发生。

    您也是另一个进程挂钩键的潜在受害者,该进程在您之前并且未正确调用 CallNextHookEx()。使用 TaskMgr.exe 的“进程”选项卡来解决这个问题并开始杀死进程。从任何闻起来像供应商提供的铲子的东西开始,特别是如果键盘的键不适合WM_APPCOMMAND command set,因此需要这样的程序来添加小玩意。

    【讨论】:

    • 按照 Hans 的建议,我会在安装了全新 Windows 的 VM 上对其进行测试,以消除第三方软件。
    • 谢谢。原来是Microsoft IntelliType Pro。我终止了进程,我的代码按预期工作。
    • 问题:对此我有什么办法吗?任何先到达那里的进程都可以在我有机会阻止它之前做一些事情。有没有办法确保我的代码是第一个处理消息的?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多