The old mobile module would pop up they keyboard every time an input box gained focus. For label scanning this required us to manually hide the keyboard each time.
If we could have the option for control over when or if to have the keyboard pop up, or use the default keyboard for the browser with calls to hit the CRLF button after input would also be great.
Pre-8.0.0
Browsers on phones do this automatically.
Options would be to use the preventDefault functionality of the event & action system (we’d have to experiment with this, I’m not 100% sure it would work) or alternatively I’ve been thinking about a quasi-field component whose job it would be to consume information coming from a keyboard-wedge style input device (e.g. a true laser barcode scanner), without the browser thinking that it was actually an input field.
Bar code scanners and scanner control are critical for us. Right now we use the Scanner module in Vision. All our scanners that we use with Ignition have a preamble of \u0002 and a \u0003 postamble around the scanner data.
In thinking about your component more… In JS in the browser, can you monitor keystrokes regardless of focus? If so, that component could “activate” similar to the current scanner module when a specific character (or sequence) is seen. The contents of the typing after the preamble could then be made available via an event handler.
This not only helps with barcode scanners, but anything that follows HID protocol. (We have done the same with pcProx RFID readers). As long as you can configure some predictable preamble and postamble/timeout to how the data is wrapped by the HID device.
Yes, we can do something like having a component that monitors all keyboard input. I like the preamble/post idea too, that would help prevent it from being too greedy.
Which scanners do you use?
Mostly Zebra (formerly known as Motorola… formerly known as Symbol…) The DS6878 and DS2278 models. Programming options on the Zebra scanners is nearly limitless.
Our 2D bar codes have quite a lot of content (upwards of 200 characters) so having something that can keep up with the speed is important as we set the keystroke delays on the scanners to a minimum which I think is about a 1 ms keystroke delay.
Ok so these are standalone scanners, connected to a PC or tablet?
Yes, for PC they follow HID protocol so appear to the OS as a typical HID keyboard device. For iOS/Android you pair via Bluetooth.
Got it. I think a dedicated component is going to be the way to go, rather than fussing around with trying to get normal input fields to behave the way we want.