With the old mobile module, it was difficult to create a form that would automatically move from field to field as they were populated.
Can we get some better control for how to move from one field to another when a form is being populated without needing the user to touch each input field?
For example, someone scanning in a raw component label with multiple barcodes, have it go from inputBox1 to inputBox2 based on the property for focusOrder
Interesting. How would one field know it’s done receiving input, and that it’s time to move to the next field?
Tab or Enter at other apps work?
I can imagine a preset length. 13 character UPC or date for example. After being fulled the input box would know to move on…
One method could possibly be that after scanning, input = input+CRLF, then using the keyEvent to see when the CRLF “happens” it would then move on to the next in “line” of the focusOrder.
If tab/enter are the only worries than their should not be an issue as this would be the native behavior of the browser. The only important part would be ensuring that Perspective allows us to define the tab order of the fields so the browser can advance in the correct sequence.
If we are talking barcode scanners… You can program the scanner to append a tab/enter after the scan data. But, I would much rather have more control pragmatically over the input and just have a component where I can send the barcode scanner data via scripting to any field I want, give a lot more flexibility for more scenarios. See: http://forum.inductiveautomation.com/t/feature-better-keyboard-controls/20208
Exactly what I was thinking. Not always will we have control over carriage return from a wedge scanner - Think phone camera - we won’t be able to add a “return” when coming back from the image scanner.
The order part is going to be pretty easy using
tabindex properties on the input fields. I can’t think how we’d do the programmatic tabbing to next input is something right now, but it’s an idea worth investigating.
I used a Cognex MX-1502 scanning sled with an iPod touch in it (the Cognex sled works with iOS or Android devices).
One dimensional barcodes were in the 3 of 9 format, with 5 separate barcodes. Two dimensional barcodes in PDF417, but we have used data matrix also.
This is all in the old mobile module, obviously “translation/replacement" needed for 8.0/Perspective…
The old mobile module had the keyboard (separate from the browser keyboard) that would pop up when the text field gained focus, which I would have to manually minimize if I wanted to see what had happened behind it.
I also had to keep it as thin as possible, or I would get locked up. Each window had as few functions as possible and the scripts ran on the gateway
After the initial window, the operator hits one of the log in buttons
First, when the first log in window opens, there is a text field that uses the propertyChange event handler
o if event.propertyName == ‘componentRunning’
o looks at system.gui.getOpenedWindowNames()
o if window == “Badge Screen”
o system.gui.getWindow(“Badge Screen”).rootContainer.getComponent(“Text Field”).requestFocusInWindow()
Secondly, in the keyTyped event handler had the following
CR = “\r”
LF = “\n”
RK = “\0”
CRLF = ‘\r\n’
if event.keyChar == CR or event.keyChar == LF or event.keyChar == RK or event.keyChar == CRLF:
badge = event.source.text
The Cognex scanning sled (MX-1502) takes the barcode scanned and can be configured to add a CRLF to the end of the scan.
I used this method for every window I needed a scan input for, with variation for what the next window needed to be
I could not use this for multiple text fields as the focus would return to the first one.
Another variation I had was, on some windows that I needed to scan to the same field over and over
- I would have another component have a propertyChange event handler that would do the following
- then the text field re-requests focus and the existing text is highlighted.
Another was for the 2D (PDF417, but works with other 2D types) scan.
- Behind the scenes it does parse for the 2D string and writes the values to tags.
- Then writes the data to the database and shows the message
So I guess the feature improvement would be that I could scan all into one screen and have something like focusOrder() to allow me to set 1st, 2nd, 3rd, etc., etc. All without needing someone to touch the screen or a tab key (and no mouse attached to click) for each step.
Hmm, raises another question/suggestion: some kind of alpha-numeric scanInputBox component that would account for the above…?
In addition to this concept, for a purely non-keyboard type environment, we would need a way to trigger things happening. For example, onStartup of a view, trigger focus on the first input field, scan, trigger move to next input field, etc, etc…
These devices are for both indoor warehouse scanning and outdoor logistics/inventory moving. When outdoors, often in bad weather, these will need no hand entries if at all possible. Trying to type on a small screen in the winter with gloves on? Or summer storms? The sled provides the CRLF in addition to the scan, but I need a way to trigger focus without users having to touch the screen, especially for multiple entries.
We’re working on a new component to help support barcode scanners. Currently, you don’t need any sort of focus and we intercept and append the scans to a data object on the component, which you can then consume. Would that functionality replace the need to go input field by input field?
So for example, you could show the user a message to scan something, then they scan, then you intercept that scan and possibly display the data that was scanned if desired?
(Skip the “input field” all together?)
Yeah exactly. The scans just show up as a property on the component that you could then listen for changes.
That would vastly simplify my project… show message, listen for scan, put barcode value into the correct tag, show next message, listen for next scan, put next barcode in correct tag, “rinse and repeat” until complete… display all values scanned upon completion…
Speaking of, what would be the correct “client” location for those perspective tags so one device won’t “step on the toes” of another? Just in the All Providers/Default and each device will be a new instance of the tags? Or will this need to work more like the vision client style?
Will this also include the ability/props to designate which symbologies to listen for and ignore the rest?
For this, I’d put them in the
session.custom properties, rather than tags.
And these would be values or arrays, but not objects, correct?
Also, what would be the calls to read/write to the session.custom properties? (I am not seeing them in the 8.0, but I may have missed them…)
You can reference them from a script like this:
So for example you could do something like
self.session.custom.foo = “bar”