I am trying to get a string input from a USB barcode reader seen as a keyboard. I have created this small VI to test the concept. With the input string on "update while typing" it works just fine (The false case is just a condition on i so that the while loop exists even if no input is registered.
However, when I copy this code in an event case of my main VI with the exact same settings, the loop times out without seeing the string input from the keyboard/barcode reader. Only when it exists the while loop is the keyboard updated in the string control.
Any idea what could cause this behavior?
Thanks in advance.
Solved! Go to Solution.
Set your scanner to end read with Linefeed and it should create a Value change event just like when you write directly and press Enter.
Thank you for the suggestion. My scanner was already set like this, but when I tested my code I had unchecked the "limit to single line" option of the string control. Now I detect the value change as you predicted. I am working on a different part of the code, but I will try testing my main code with your suggested fix very soon, and will post again when I have a result.
Showing up a little late on your posting but I'd like to offer a suggestion for your longer-term consideration.
USB-interfaced scanners that I've used can be changed from virtual keyboard wedge mode (what you presently use) to virtual serial port mode. Over the many years I've dealt with barcode interfaces in LabVIEW, I've used both approaches and long ago settled on serial.
The advantages of a serial interface are that you never need to worry about what control has focus (and forcing focus on a specific control is frequently a UI nuisance to the user); and you never know when a user may type random chars into your string control which may end up concatenated into the value you receive.
I setup a virtual serial port in VISA, alias it (in MAX) with the name "BARCODE" (so my code doesn't require the device to be a specific COMx value), then have a separate loop that issues VISA read calls using whatever termchar the barcode reader uses. I set a short timeout (which is the expected behavior), and when it doesn't timeout, I send the string to the UI handler (typically as a user event). Now the barcode input can peacefully coexist with all other user interaction. I also enable the barcode device to prepend the industry-recognized barcode types (generally called the "AIM ID"); this plus string length and some pattern matching allows you to distinguish what target the user has scanned.
That's a good suggestion. I will look into it when I get more time. For now I am keeping the "virtual keyboard" behavior as we have other applications already using this mode.
Thanks a lot for your help.
Thanks again for your help, it now works perfectly with the value change event. I think issue was caused by other controls interfering with the barcode input control. In any case, your solution is much simpler and cleaner than anything I had tried.