Strange string control behaviour in built app

[Martin.D]

I have a machine in Japan that they use a hand scanner to enter some data into a string control. The data is typically something like “487\n”. Normally when they scan some data the string control will display “487” but when the application is built into an exe file the string control displays “487J”. I have tried the following to resolve this issue:

1. Limited the string control to a single line – no change
2. In the build properties I have explicitly set the language to default to English – no change.
3. Changed the control to display codes display – no change

Has anyone any ideas what’s going on?

Using LV 8.01 on XP pro

TIA

-Martin

[JB]

What is displayed if the code is scanned in a text editor (notepad, word...) ?

[Martin.D]

Notepad displays "487", LabVIEW displays "487J" very strange!

[JB]

...and this unexpected behavoiur only appears with the EXE...

The only idea that comes to my mind is to verify below options :

• LabVIEW options --> LV menu >> Tools >> Options... >> Environment : is the End text entry with Enter key option checked ?
  
• Builder specifications --> Project Explorer >> Build Specifications >> settings for the EXE >> Advanced : is the Use the default LabVIEW Configuration file (LabVIEW.ini) option checked ?

Message Edité par JB le 02-29-2008 09:00 AM

[Martin.D]

Hi,

It’s not easy for me verify the above setting as the machine is production and in Japan. But the setting you mention will be at the default settings.

I have the built application here and I can’t re-create the problem buy pasting or typing in data that ends with a \n. So I guess it may be something to do with the way the scanner inputs the data. Maybe it streams the characters too fast or something. But it always displays a “J” at the end for a given barcode in the LabVIEW string control. I can’t remember the exact barcode they were scanning just that it ended with a /n. I think it may have been TEST1, or TEST-1.

I’ve just tried scanning data into the application here and it fine. But this scanner does not terminate with a /n. I think I’ll try deleting and recreating the string control next time I get a chance. Beyond that I may suggest they try a different scanner.

-Martin

[RobBoyer]

Hey Martin,

Probably not particularly helpful, but just in case, note that newline and J are only off by one bit -

newline = 0xA or 00001010

J = 0x4A or 01001010

The fact that it works in notepad indicates to me that it is not an issue with the scanner hardware.  Scanners typically do nothing but send characters exactly as a keyboard would do.  Apparently the LabVIEW runtime or one of its dependencies is mangling the data.

Anyway, just some observances.  Hope it helps, (somehow) 😕

Rob