Best way to handle input from a keyboard "wedge"

Question

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.

Heterography

Answer 1

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.

Kattegat

Answer 2

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 KeyPress attach or a low-level keyboard hook via SetWindowsHookEx() or via KeyPreview on 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.

Jem

Answer 3

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.

Incredulous

Answer 4

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?

Jazzy

Answer 5

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.

Leyden