问题
I'm in the initial stages of developing a companion application to an existing POS program. Basically I'm looking for pin pad like functionality. We have a Targus USB numerical keypad and want this available to the customer to enter a PIN number. (This is NOT for a payment system, just a customer account verification). The main POS program will be running, but I need my application to run in the background and wait for a PIN to be entered which it will then authenticate.
Possible Solution #1: I downloaded a sample project from Code Project that addresses USB HID devices by VID & PID. this would be perfect, however keyboards are somehow protected by Windows and cannot be accessed this way. Is there a way to "Unreserve" the keypad in Windows so its still a HID device, but not seen as a keyboard?
Possible Solution #2: There are samples of keyboard hooks, but these wont work either as the keypad output will still go to the POS application. I need the keypad output to ONLY go to my background application no matter what program has focus. Is there a way to redirect output from a specific keyboard to a specific application?
This will be rolled out to 100+ POS terminals in remote locations so a solution that doesn't require re-configuration of windows would be preferable. It also needs to be in C# .NET 2.0
回答1:
Your best option is to buy a Joystick "Keyboard" so that you can read the device (USB HID) as a non-keyboard/non-mouse (as keyboards and mice are restricted by OS, non-bypass-able because it's hard coded into the Device Management.)
What I would recommend is looking an PI Engineering's keyboard as their keyboards can be registered as joysticks. They have custom mapping software that simulates pressing a key on their devices to sending a key in the windows messaging queue (simulating a keyboard). Instead you can just program directly against the device (As each key is just a joystick button) using their SDK and won't interfere with the POS software.
PI Engineering Programmable Keyboards
USB access description (Relevant section listed below in case the link dies)
Microsoft Windows
Windows Driver Development Kit HID
The Windows DDK HID API is like the Apple HID Manager in that is a complicated, low-level API that closely mirrors USB HID. A program can access more or less every device, both input and output, except for the keyboard and mouse, which Microsoft has deliberately blocked from this API. Unlike the other APIs covered so far, the nature of the reading mechanism makes it quite difficult to use without having a thread dedicated to reading events from the queue. While at first glance it may seem necessary to purchase Microsoft's Driver Development Kit in order to use this API, it is possible to use it with the free MinGW tools.
In Windows, notifications of device plug and unplug events are sent to a window handle, so in order to receive them the hidio object needs it's own (invisible) window which can then receive the notifications. In the current implementation the object automatically rebuilds the device list when it receive such a notification. Additionally, in case a device is currently open it checks whether the device is still connected or got removed.
DirectInput
Microsoft's DirectInput API provides a relatively straightforward interface, but at the expense of flexibility. It has limited support for the USB HID device types and mainly aimed at the most popular gaming devices; in USB HID-speak, it only supports the `Generic Desktop Page'. It does provide access to the mouse and keyboard data, but not as individual devices. If there are multiple mice or keyboards attached, then all of the data is lumped into one virtual device. It does support Force Feedback, but not any other output type. Like Linux input.h, it has its own simplified event scheme, and also automatically scales some of the incoming data, which can be problematic.
Windows Raw Input
Raw Input is a new API as of Windows XP that was provided in response to developers' desire to get raw access to the keyboard and mouse. It is the only way to get raw data from mice and keyboards on Windows. With Raw Input, it is possible to get the input events for any USB HID device, but output is not supported at all. For this reason, we have not explored Raw Input deeply yet, but we will probably use it in order to fully support keyboards and mice on Windows.
回答2:
I crossed this bridge for a POS solution once. I found that a keystroke is a keystroke is a keystroke, plain and simple. Without writing your own device driver, I was unable to find a way to accomplish this.
So, our approach was simply to disable input access for the cashier while waiting for the customer to input their pin and vice versa when the cashier should have input access and not the customer.
I know it is not the answer you wanted to hear, but it is the one I found through experience.
EDIT: Something to explore... Dealing with COM ports directly is pretty easy. Rather than a USB device you may consider a COM keypad device. That would give you much greater control of the output of the device. COM is a pretty old tech and finding POS machines with those ports might be hard. This was not an option for us so we never explored it.
来源：https://stackoverflow.com/questions/13923436/redirect-keyboard-input-from-second-keypad