处理来自键盘“楔形”输入的最佳方式
我正在编写一个 C# POS（销售点）系统，该系统从键盘楔形磁卡读卡器获取输入。 这意味着它从磁条读取的任何数据都可以像在键盘上快速输入一样被输入。 目前，我正在通过附加到 KeyPress 事件并查找一系列包含刷卡哨兵字符的非常快速的按键来处理此问题。
有没有更好的方法来处理这种输入？
编辑：该设备只是将数据显示为击键，并且不通过其他驱动程序进行交互。 此外，我们使用各种此类设备，因此理想情况下，一种方法应该独立于所使用的楔块的具体型号而工作。 但如果没有其他选择，我就只能凑合了。
I'm writing a C# POS (point of sale) system that takes input from a keyboard wedge magcard reader. This means that any data it reads off of a mag stripe is entered as if it were typed on the keyboard very quickly. Currently I'm handling this by attaching to the KeyPress event and looking for a series of very fast key presses that contain the card swipe sentinel characters.
Is there a better way to deal with this sort of input?
Edit: The device does simply present the data as keystrokes and doesn't interface through some other driver. Also We use a wide range of these types of devices so ideally a method should work independent of the specific model of wedge being used. However if there is no other option I'll have to make do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我同意@jttraino的想法。
这是条码扫描/读码器和其他即插即用 (PnP) 此类设备的最佳选择。 在我之前的任务中，我使用了相同的技术来配置几个一维和二维条形码扫描仪。
I second @jttraino's idea.
It is the way to go for bar scan/code readers and other such devices that are plug and play (PnP). I have used the same technique to configure a couple of 1D and 2D bar code scanners in my previous assignment.
另一次投票支持 jttraino 的想法。 我对销售点系统中的读卡器和支票阅读器做了同样的事情，我们需要支持键盘楔以及 USB 和 RS232。
基本上，选择不太可能来自键盘的短字符序列，并对消息处理循环进行编程以查看这些字符的到达。 如果您获得与模式匹配的完整字符流，则可以对输入的其余部分进行解码，直到到达指定的“结束”序列，或者直到您确定传入序列有错误。 考虑到编辑蒙版和各种屏幕的行为等情况，选择一个很难或不可能从常规键盘输入应用程序的字符串。
一个好的起点是像 tilda-pling (~!) 这样的字符，因为这些字符不太可能出现在任何人的个人详细信息中，也不太可能需要一起出现在注释文本等中。:-)
缺点，正如 jttraino 所说，您可能必须对每个读卡器设备本身进行配置/编程。 一些制造商使这变得相当容易 - 您使用谁的套件？ 马格泰克？ 韦尔奇·艾林？
Another vote for jttraino's idea. I do much the same with card-readers and cheque-readers in point-of-sale systems where we need to support keyboard wedge as well as USB and RS232.
Basically, choose a short sequence of characters unlikely to come from the keyboard, and program your message handling loop to see these characters arriving. If you get a completed stream of characters that match your pattern, you can decode the rest of your input until you hit your designated 'end' sequence, or until you decide the incoming sequence is in error. Select a string that is either difficult, or impossible, to enter from the regular keyboard into your app given things like edit masks and the behaviour of your various screens.
A good starting point is something like tilda-pling (~!) as those characters are not likely to appear in anyone's personal details and not likely to ever need to appear together in the text of a note, etc. :-)
The downside, exactly as jttraino said, is that you will probably have to configure/program each reader device itself. Some manufacturers make this fairly easy to do - whose kit are you using? Magtek? Welch Allyn?
我认为您正在以可接受的方式处理它，只需注意卡发送数据的速度，我们有无线条形码扫描仪，并且时不时地它们会在键盘上快速敲击键盘以供应用程序处理。
另外，如果您将软件分发到其他地区，那么按键可能会有所不同，例如在西班牙（我认为，但可能是法国）键盘的顶行是 !"£$%^&( ）与 USA/UK 1234567890 相反，如果您的读卡器设置为 usa/uk 那么它将发送 !"£$%^&() 代替 1234567890，因为楔子只是模拟该密钥被按下，如果 Windows 解释它不同，那么它是你的问题。
I think you are handling it in an acceptable way, just be careful of how fast the card sends the data, we have wireless bar code scanner's, and now and again they throw the key strokes at the keyboard to fast for the application to handle.
also if you are distributing your software to other territories, then key stokes may be different, for example in Spain (I think, but may be France) the top line of the keyboard is !"£$%^&() opposed to the USA/UK 1234567890, and if your card reader is set to usa/uk then it will send !"£$%^&() in place of 1234567890, as the wedge just emulates that key been pressed and if windows interprets it different then its your problem.
如果您提前知道设备的硬件 ID，您还可以使用原始输入 API。 我最近在博客上谈到了这一点. 这可能很疯狂，但它满足了我的要求：在我的例子中，主要目标是即使应用程序由于有人在翻找扫描托盘上的物品时不小心撞到东西而失去焦点时也能够接收输入。 第二个目标是我无法添加任何哨兵字符，因为这会破坏与扫描枪一起使用的现有第三方应用程序。
不过，我之前已经完成了哨兵字符方法，无论是通过
KeyPress附加还是通过SetWindowsHookEx()或通过KeyPreview的低级键盘挂钩code> 在应用程序的主窗体上。 如果它满足您的要求，那么使用该方法肯定会更简单、更容易，为此我赞同已经给出的建议。You can also use the Raw Input API if you know the Hardware IDs of the devices ahead of time. I blogged about this recently. It may be insane but it satisifed my requirement: the primary goal in my case was to be able to receive input even when the application lost focus because someone accidentally bumped into something while rummaging around to scan items on a pallet. The secondary goal is that I couldn't add any sentinel characters because that would have broken existing third-party applications being used with the scan guns.
I've done the sentinel character method before, however, both via a
KeyPressattach or a low-level keyboard hook viaSetWindowsHookEx()or viaKeyPreviewon your application's main form. If it meets your requirements, it's definitely much simpler and easier to use that method and to that end I second the recommendations already given.您可以做的一件事是您应该能够配置楔形读取器，以便它在字符串之前或之后显示一个或多个转义字符。 您可以使用这些转义字符来知道您即将拥有（或刚刚拥有）磁卡输入。
条形码读取器设备也使用相同的技术，因此您的应用程序知道获得焦点或处理来自设备的数据输入。
这种方法的缺点是您必须正确配置外部设备。 这可能是部署问题。
这假设您的设备只是将数据显示为击键，并且不通过其他驱动程序进行交互。
One thing you can do is that you should be able to configure your wedge reader so that it presents one or many escape characters before or after the string. You would use these escape characters to know that you are about to have (or just had) a magcard input.
This same technique is used by barcode reader devices so you application knows to get focus or handle the data input from the device.
The negative to this approach is that you have to properly configure your external devices. This can be a deployment issue.
This assumes that your devices simply present the data as keystrokes and don't interface through some other driver.