.NET 或操作系统对物理按键和编程按键的处理方式是否不同
首先是一些背景信息...
我有一个在平板电脑上运行的 C# .NET 应用程序，即没有物理键盘。我们使用 Windows XP 平板电脑版本中内置的屏幕键盘来填充表单上的 TextBox 控件。表单没有特殊的按键处理（尽管 UI 的其他组件确实处理按键）。
有时，屏幕键盘会停止记录某些按键。该表单仍然具有焦点，并且光标仍保留在文本框中。反复点击某个键最终会显示该字符。我们的应用程序使用许多繁忙的处理线程，但 CPU 利用率远未达到 100%。
当发生这种行为时，它会保持这种状态，直到我们的应用程序重新启动为止，之后键盘就会正常工作。当连接 USB 键盘并用于输入时，根本不会出现此问题。
我对物理按键和编程按键之间有什么区别感兴趣？编程按键是否会像物理键盘一样产生硬件中断？ .NET 是否可以以不同的方式处理每种类型？
任何有助于调试问题的建议将不胜感激！
Firstly some background information...
I have a C# .NET application that runs on a slate pc i.e. no physical keyboard. We are using the on-screen keyboard built into Windows XP Tablet edition to populate TextBox controls on a form. There is no special key press handling for the form (although other components of the UI do handle key presses).
Occasionally the on-screen keyboard will stop registering some key presses. The form still has focus and the cursor remains in the text box. Repeatedly tapping a key will eventually cause the character to be displayed. Our application uses a number of busy processing threads however it is far from 100% CPU utilisation.
When this behaviour occurs it remains that way until our application is restarted, after which the keyboard behaves normally. The problem does not occur at all when a USB keyboard is attached and used for input.
I'm interested in what differences there are between physical and programmatic key presses? Do programmatic key presses generate hardware interrupts as a physical keyboard would? Could .NET be handling each type differently?
Any suggestions that could help debug the problem would be much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从未使用过 XP OSK 的平板电脑版本，但我使用过 XP Embedded 版本。据我所知，Windows API 以相同的方式将按键发送到 .NET 和 MFC 应用程序。事实上，如果我没记错的话，我们无法通过编程来区分两者之间的区别。据我所知，OSK 不会导致硬件中断，但是虚拟键代码将以与物理键完全相同的方式发送到应用程序级程序。
除非您正在运行自定义驱动程序或其他东西（可以访问硬件层），否则听起来可能不是您的应用程序导致了问题。
如果您还没有这样做，我会检查触摸屏是否具有最新的驱动程序并且是否已正确校准。我还会检查 OSK 是否具有 Microsoft 的所有最新更新。
I've never worked with the tablet version of the XP OSK, but I have used the XP Embedded version. As far as I could tell the Windows API was sending key presses to .NET and MFC applications the same way. In fact, if I recall correctly, there was no way for us to tell the difference between the two programatically. As far as I know an OSK will not cause a hardware interrupt, however the virtual-key code will be sent to application-level programs in the exact same manner as a physical one.
Unless you are running a custom driver or something (that has access to the hardware layer), it sounds like it may not be your application that is causing the problem.
If you haven't already, I would check that the touchscreen has the latest drivers and is properly calibrated. I'd also check that the OSK has all the latest updates from Microsoft.