精确响应 Windows 中的平板电脑/鼠标事件

发布于 2024-08-06 15:57:09 字数 1242 浏览 4 评论 0原文

如何告诉 Windows 不要对数位板笔事件进行无用的预处理？

我正在使用 Python 2.6 进行编程，目标是运行 Windows 7 的平板电脑（尽管我希望我的程序只需稍作修改即可在带有 SMART 交互式白板的 XP 上运行，并且适用于 Linux/Mac 上的鼠标用户）。我编写了一个程序，它可以连接到普通的 Windows 鼠标事件、WM_MOUSEMOVE 等，并在画布上书写。

问题是鼠标消息在到达我的应用程序之前就被篡改了。我发现，如果我进行长笔划并在笔划之间暂停，则鼠标消息会正确发送。但如果我进行了几次快速的短笔画，那么某些东西就会进行无用的预处理。具体来说，如果我进行大约 10 像素长的向下笔画，然后在第一个笔画的右侧再进行大约 5 个像素的向下笔画，则第二个 WM_MOUSEDOWN 报告它来自与第一个完全相同的位置。

这看起来像是某种预处理，也许是为了让幼稚的应用程序不会对双击感到困惑。但对于我的应用程序来说，我想要对快速手势做出非常忠实的响应，这是没有帮助的。

我找到了对 MicrosoftTabletPenServiceProperty 原子和 CS_DBLCLKS 窗口样式的引用，并使用以下 Python 代码将它们都关闭了：

hwnd = self.GetHandle()  
tablet_atom = "MicrosoftTabletPenServiceProperty" 
atom_ID = windll.kernel32.GlobalAddAtomA(tablet_atom)  
windll.user32.SetPropA(hwnd,tablet_atom,1)  
currentstyle = windll.user32.GetClassLongA(hwnd, win32con.GCL_STYLE)  
windll.user32.SetClassLongA(hwnd, win32con.GCL_STYLE, currentstyle & ~win32con.CS_DBLCLKS)

但它没有任何效果。

我尝试使用 SetWindowsHookEx 为鼠标驱动程序编写一个低级挂钩，但它不起作用——显然，鼠标消息甚至在发送到我的低级 Windows 挂钩之前就已被预处理。

我将非常感谢有关如何关闭此预处理的建议。我不想切换到 RealTimeStylus，首先是因为它无法在 Windows XP 和 SMART 交互式白板上工作，其次是因为我看不到如何在 CPython 中使用 RealTimeStylus，所以我需要切换到 IronPython，然后我的代码将不再在 Linux/Mac 上运行。

达蒙.

原文

How can I tell Windows not to do unhelpful pre-processing on tablet pen events?

I am programming in Python 2.6, targetting tablet PCs running Windows 7 (though I would like my program to work with little modification on XP with a SMART interactive whiteboard, and for mouse users on Linux/Mac). I've written a program which hooks into the normal Windows mouse events, WM_MOUSEMOVE etc., and writes on a canvas.

The problem is that the mouse messages are being fiddled with before they reach my application. I found that if I make long strokes and pause between strokes then the mouse messages are sent properly. But if I make several rapid short strokes, then something is doing unhelpful pre-processing. Specifically, if I make a down-stroke about 10 pixels long, and then make another downstroke about five pixels to the right of the first, then the second WM_MOUSEDOWN reports that it comes from exactly the same place as the first.

This looks like some sort of pre-processing, perhaps so that naive applications don't get confused about double-clicks. But for my application, where I want very faithful response to rapid gestures, it's unhelpful.

I found a reference to the MicrosoftTabletPenServiceProperty atom, and to CS_DBLCLKS window style, and I turned them both off with the following piece of Python code:

hwnd = self.GetHandle()  
tablet_atom = "MicrosoftTabletPenServiceProperty" 
atom_ID = windll.kernel32.GlobalAddAtomA(tablet_atom)  
windll.user32.SetPropA(hwnd,tablet_atom,1)  
currentstyle = windll.user32.GetClassLongA(hwnd, win32con.GCL_STYLE)  
windll.user32.SetClassLongA(hwnd, win32con.GCL_STYLE, currentstyle & ~win32con.CS_DBLCLKS)

But it has no effect.

I tried writing a low-level hook for the mouse driver, with SetWindowsHookEx, but it doesn't work -- obviously the mouse messages are being pre-processed even before they are sent to my low-level Windows hook.

I would be very grateful for advice about how to turn off this pre-processing. I do not want to switch to RealTimeStylus -- first because it won't work on Windows XP plus SMART interactive whiteboard, second because I can't see how to use RealTimeStylus in CPython, so I would need to switch to IronPython, and then my code would no longer run on Linux/Mac.

Damon.

分享到QQ

分享到微博