04-30-2019 07:00 AM
I am building a piece of test software where a step is the user will scan the serial number barcode with a barcode scanner. So far, I have been entering '0123456789' on the 10 digit keypad. When trying to test it with a proper barcode scanner, or the numeric keys on the top of the keyboard, it seems like the entry is not recognized by LABView. I have attached the two VIs. Maybe there's a property of the string box I am missing?
Thanks.
Solved! Go to Solution.
04-30-2019 07:20 AM
Your VI's seem to work for me. Perhaps there is something wrong with your keyboard?
If it doesn't work for you, give more explicit instructions as to what we need to do or enter in order to make it not work correctly.
Why are you using the Text.Text property node? It would be more logical to use the Value property node. And really the wire is available to provide the data when the User Input terminal is sitting there unused. You should make an event case for the Okay and Cancel buttons as well, then you can get rid of the timeout case.
04-30-2019 07:31 AM - edited 04-30-2019 07:32 AM
Thank you for your input.
Here's how I have tested this:
10 digit keypad on top of letters - Does not recognize entry
10 digit number pad on the right of my key board - works fine
barcode scanner with programmed return carriage entry - does not recognize entry
I'm going to grab a different keyboard and see what happens. I also have tried the express VI for user input and all three methods there, but I've read that in most instances, those should be avoided.
For the cases on the okay/cancel buttons, would their respective cases just be wired to the ORs they are wired to already? I don't see another way to handle that.
04-30-2019 08:16 AM - edited 04-30-2019 08:43 AM
I see something backwards in your subVI.
Your OK button triggers the Cancel-button indicator.
The Cancel button does not.
Here is a modified, simplified subVI
04-30-2019 08:22 AM - edited 04-30-2019 08:25 AM
I think I have found the solution. In this instance, I do want to use the text.text property node, not the value. This knowledge article explains better.
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YxnSAE&l=en-US
Thanks for pointing out the cancel button. I've looked at this VI a bunch and hadn't noticed it.
04-30-2019 08:47 AM
@BHopkins123 wrote:
I think I have found the solution. In this instance, I do want to use the text.text property node, not the value. This knowledge article explains better.
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YxnSAE&l=en-US
Thanks for pointing out the cancel button. I've looked at this VI a bunch and hadn't noticed it.
That article makes sense. But I don't think it applies to your situation. By the time you hit enter or the OK or cancel buttons, the text will have already been validated in the control.
Although that does give me a theory on why it might not be working for you. If you hit enter while in the string control, the string will contain your 10 digits AND the carriage return. Your string length will then be 11. But in that case, I wouldn't use text.text which is a very rarely used property node. I would just clean the string of trailing carriage returns or linefeeds before exiting the subVI.
It doesn't explain why using the top row number keys would cause you a problem.
04-30-2019 08:57 AM
I also just saw your reply with the modified VI. Which led me to do some reading on using property nodes vs local variables. Which, in my case, the local variable will suffice fine (the Main VI is a state machine). I also didn't know that property nodes were way slower than variables in this instance.
With the local variables, it operates as intended, and I've also changed around my other SubVIs for user input to match it. Thanks!