I have a small Android app that utilizes a barcode scanner on an Android device. Like most of these scanners, the manufacturer included a small app to control the scanner and make it act in different ways. Most commonly, this is to make the scan appear as keyboard input.
To make this work one must know when the barcode ends. This is typically with the key, and Xojo includes the event MobileTextArea.ReturnPressed to capture this. And sure enough, if I manually enter my barcode data and press the event fires.
However, my scanner wedge is sending the barcode text over with the trailing (tested in other apps) but the event does NOT fire. I can press after scanning and it works.
This is quite the problem. I am asking if anyone has a suggestion on this matter. The barcodes are not fixed length so checking that is off the table.
Is the chr(13) / chr(10) / whatever it is ending up as a character in the text? If that’s happening you could parse the field in TextChanged assuming it’s being raised.
As for ENTER vs RETURN, the barcode wedge app does not give me that option. I get only TAB and ENTER (not RETURN, as I mistakenly stated before). My client purchased an inexpensive scanner, so the options are a bit limited.
I have no idea on how I might add a pause. The labels are already printed, or I would have them use some control character to indicate end of label.
I did look for the termination character by parsing out each character, but did not see anything. Apparently Xojo considers text changed as human-readable text and the RETURN is not a sufficient condition. I will, however, double-check my work on this as this is my preferred method.
My next step is to watch for the end of data entry and then validate the data. I will set a timer on each character coming in and if it expires before another character arrives I will process what is there. I would have done this sooner, but the TextArea also allows keyboard input, which is slower, and I must allow for us dumb humans to play along.
Most barcode scanners have some degree of programmability - pressing Enter after transmitting a barcode is a simple example of how they can be configured. Adding a small pause before Enter is a common option. It doesn’t involve any changes to the barcodes.
It is a Tera P172. Firmware v26.1.02. It is using a utility called keyboardemulator v11.4.3M. Looks like it is the same as that used by MUNBYN scanners.
I see no option for a pause and I did confirm that there is no data triggering the TextChanged event after the actual barcode. Oh how I wish Android supported KeyDown like iOS but we works with whats we got, as the old phrase goes.
That is correct. The “wedge” is a bit of firmware or the app that pulls from the scanner and pushes to the destination.
I haven’t used the word “shockingly” (yet) but it is certainly lacking. When I tested my app on a higher end scanner a couple of weeks back it worked fine.
I have managed to implement a time-controlled scheme that I am testing now. I refined it down to a simple time extension before processing. I know the minimum number of characters is nine and that they take about one second to be loaded from the wedge app. The max is 13 characters so when I get the first nine I start a Callback Timer for 500 msec and process whatever is in the TextArea. I ONLY do this if the device is in scanner mode; if in keyboard mode the user pressing the RETURN key kicks off the processing.
Admittedly, this is a lousy way to do things, but at this point I see no alternatives.
Looking at the user guide regarding keyboard emulation settings…
Process mode can be “Scan content on cursor” or “Keyboard input”. Have you tried both settings?
End mark can be enter, tab, or space. As was said previously, tab would presumably trigger FocusLost. Space is something you could detect in TextChanged.
There are settings for a prefix and suffix, which you could use instead of the enter key for detecting scanned values. The example in the manual is something like ^value^ which would be easy and fast to detect if you can permit the user to briefly see those characters.
Regarding the timer for 500ms, I would think the delay between characters is pretty consistent. I suggest timing it. Start a timer for ~2x inter-character delay after the first character and then reset the timer after each subsequent character. When the timer fires, process input. Then, depending on how fast it types, you won’t have to wait a full 500ms if there aren’t any characters after the first nine.
I did try that, but it was of no help. Tab does not trigger OnChange or a move to the next field; it appears to be stripped out by the software wedge. Thank you for the suggestion, however. That might have worked with a “less-shockingly unconfigurable” scanner.
Interesting thought, using the prefix. If I get a few minutes I will see what that does. I suspect, however, that the software will just strip its characters out as it does with the C/R and Tab as suffixes. Infuriating.
I considered your approach to resetting the timer on every character entered, detected by a TextChanged event. This requires a numerous calls to the timer, but is certainly doable. However, I looked at what the user will do and decided that adding half a second to the scan would not be disadvantageous. Typically the user will extend his/her arm and scan the barcode. The arm will then be retracted and the user will check the screen to see if the item was validated. They may see the last of the characters going into the field and then a slight delay, which will be assumed to be communication time to the server. By they time they can reach the screen with the other hand to click the next popup box the data is validated and I only used one call to a Callback timer. In my testing this approach has worked well - I have not missed any extended scans and I may even be able to back the delay off to 200 msec.
Wait, what kinds of barcodes are you scanning? Code 39, for example, cannot encode a space character, so if you had the wedge transmit a space after scanning, you’d know for sure the scan was complete.
FYI, Code 39 does support spaces, both in the native charset and the ASCII extension. The general advice is sound though; any ordinary character or pattern of characters guaranteed not to be included in the value is fair game. As I said earlier, I believe the manual gave the example of the ^ character (e.g., ^VALUE^). Could be something like ~VALUE~ or #VALUE# or [[VALUE]] too.
