scanning 2D barcodes (with odd characters) crashes LabVIEW 8.6

[jcarmody]

Hi folks,

I'm upgrading a production program which involves scanning a 2D barcode containing non-printable ASCII characters (0x4, 0x1D & 0X1E).  This causes LabVIEW to crash quite reliably.  I've removed the non-printable characters and the problem goes away (this isn't a solution as the barcode format is specified by our customer).

I'd post my code, but all you'd need to do is drop a String control on a new VI.  You don't even need to run it; it'll crash whether the VI is running or not!  I did attach a sample barcode, however.

I tried filtering these characters from the Key Down? event, but they don't appear as key presses.  I noticed that LabVIEW doesn't crash if the String control doesn't have focus, and I can work around the problem using this fact but I never feel good when I work around problems.  I'm stumped, do you have any ideas?

Message Edited by jcarmody on 03-11-2009 08:49 AM

[TCPlomp]

,Hi Jim,

does changing the representation of the string (to Hex or /) fix the issue?

Ton

[jcarmody]

---

TonP wrote:

,Hi Jim,

does changing the representation of the string (to Hex or /) fix the issue?

Ton

---

No, I've messed with all of the control's options.

[RavensFan]

How does the scanner behave?  Like a keyboard wedge?

Can you capture the characters it is transmitting in something else like a text file in notepad and post that file?  Perhaps it is some other unexpected character in the data stream causing the problem.

Can you generate a 1D barcode with similar characters and have the scanner read that?   In case it is something about the 2-D nature driving the problem.

Any error messages when LV crashes?  Or on reopening and recovery in LV?

Message Edited by Ravens Fan on 03-11-2009 10:37 AM

[jcarmody]

• Yes, like a keyboard wedge.  It's a USB device, not actually connected to the keyboard like old, hardware, keyboard wedges.  I think...
• Characters are attached in a PDF file. 
• Perhaps I can generate a 1D barcode as you suggest.  Let me get back to you.
• The error message isn't very helpful.

Message Edited by jcarmody on 03-11-2009 09:51 AM

[RavensFan]

Here is something interesting I see. The .pdf shows some odd characters (the triangle, double arrow, diamond).  But when I look at them in LV, I see them as hex 2E which is a decimal point.  (Normal, \codes, hex display)

I'm not sure why you posted the characters using a .pdf instead of a text file.  You could have some font thing going on with the pdf complicating this that isn't the source of your problem

Message Edited by Ravens Fan on 03-11-2009 11:11 AM

[jcarmody]

I posted the PDF to show the funky characters; here's the text.  I'm wondering if there's not something different when you paste it in versus when it's scanned in.  Keep in mind that this crashes LabVIEW even if the VI isn't running.  This makes me think that something changed between versions 8.5 and 8.5.

Another interesting thing to consider is that I see question marks where you show decimal points.

Message Edited by jcarmody on 03-11-2009 10:21 AM

[RavensFan]

Very, very odd.

Just so you'll know.  I got mine by highlighting the characters in the .pdf file.  Then Ctrl-C and Ctrl-V into a LV string control.

[jcarmody]

I think this is just a symptom of the original problem.  The scanner sends non-printable ASCII "characters" to the receiving application.  I used MS Word & made a PDF, but Word doesn't know what to do with these non-printables so it substituted something that it could understand.  This allows us to copy/paste it in LabVIEW without crashing because Word already handled what it considered to be an exception. 

It sure seems that LabVIEW 8.6 String controls cannot handle the same exception, either in design mode or at run-time.  I've worked around this by letting the Front Panel receive the scan.

[RavensFan]

I know string controls can handle non-printable characters.  You see them with \codes display or hex display.  You can also enter them in normal display by holding down the alt key and entering the 3 digit ascii code on the number pad.

So if having a front panel control handle the characters works for you now, how were you trying to use the scanner before?