On several occasions I’ve had to build custom input devices–dials, keypads, door sensors–that interface with a computer as a keyboard, e.g., via Arduino or custom keyboard driver. Once you get key assignment working properly (pre-Axure), it works the same whether “real” keyboard or alternate keyboard input is received. I don’t know if there is a clean way to determine which input device is being used, if that’s where you’re going with this (similar to setting up a keyboard macro on a gaming mouse–the OS just receives the input and doesn’t care from whence it came.) Most of the pain and time came with trying to get the alternate keyboard and key assignments set up in Arduino, but not an issue with a prebuilt keyboard driver, like you’ll have with your Zebra scanner. Just look for any documentation you can find from Zebra on how they set things up with your OS.
You may need to find out if the input from Zebra scanner comes in as a key down or key up event. I would expect the latter. A standard keyboard will send a keyDown and then a keyUp when a key is released (and a keyPressed if the key is held down for so many ms; to give key repeat.) Ooh, that may be one way to distinguish input devices–if you can detect a key from standard keyboard via OnKeyDown, and (maybe) only detect scanner input via OnKeyUp? Well, regardless, you’ll likely also be able to test the length of input string–one char for “human keyboard” and many for “scanner fake-keyboard.”
As I recall, I had much better luck with OnPageKeyUp and/or OnPageKeyDown (depending on device, and desired user experience) than a widget’s OnKeyUp event, even when I had to add conditional cases to test which widget had focus.
I also found it useful to make an out-of-view (not technically Hidden) input field as a kind of “pre-processing” step, say between a user selecting a “scan now” function and showing the scanner input string. So, either a rectangle widget or text field as a “fake input area” that OnClick or OnFocus sets focus on the “secret” text field, which receives the “HID” (keyboard) input, tests and processes it (maybe verifying it is numeric only, or formatting to lower case, maybe adding spaces or dashes, showing custom error messages, etc. and then showing the user the formatted IO in the visible “fake input” widget(s)
