"≤" and "≥" both interpreted as "="

[NathanTaub]

The "≤" and "≥" symbols are auto-converted to "=" when a string is processed by LabVIEW 2018, even if "UseUnicode=TRUE" is added to LabVIEW.ini (enabling Unicode also seems to randomly inject null characters which cause the XML parser to malfunction). Unfortunately, these symbols are how my database communicates upper and lower test limits, and using contextual inference is likely to cause some issues due to some tests only having one limit. I've already tried converting to bytestreams and searching for these symbols' unicode entries, but the problem is that LabVIEW will treat the ≥ symbol (U+2265) as ' e" ' (U+0065 U+0022), and this will cause the search-and-replace function to corrupt the ' "Table" ' tag and break the entire XML string. 

Has anyone else successfully overcome this issue? I'm close to my deadline on this plugin, and this is the last bug before I can start integrating it into my test modules; if anyone has any advice it would be greatly appreciated.

[Kyle97330]

---

@NathanTaub wrote:

The "≤" and "≥" symbols are auto-converted to "=" when a string is processed by LabVIEW 2018

---

You say "when a string is processed by LabVIEW 2018", but don't specify what you mean by "is processed".  How are you "processing" this string?  Are you using some kind of code that converts text to a formula node or something along those lines?

I use Unicode in LabVIEW for localization, so my use case is different than yours.  However, I did find one strategy that seemed to work well for string processing in general.

LabVIEW uses UTF-16 LE for Unicode in all its controls and indicators you see on front panels.  However, trying to use that anywhere else often breaks things (probably because of the extensive presence of \00 bytes for standard ASCII characters as well as the need to always have an even number of bytes that never get cut in half).  As such, in my code I use UTF-8 for all string processing, and only convert to UTF-16LE when it's time to display some characters on a front panel somewhere.  If I need to read from a control or indicator containing Unicode, I immediately convert from UTF-16 LE to UTF-8 before storing it somewhere.

Without knowing more details, the best I can suggest is that you write code that looks for "≤" and "≥" symbols and replaces them with "<=" and ">=" before they get to whatever "processing" you are using.  

[altenbach]

---

@Kyle97330 wrote:

---

@NathanTaub wrote:

The "≤" and "≥" symbols are auto-converted to "=" when a string is processed by LabVIEW 2018

---

You say "when a string is processed by LabVIEW 2018", but don't specify what you mean by "is processed".  How are you "processing" this string?  Are you using some kind of code that converts text to a formula node or something along those lines?.  

---

I agree that the given information is insufficient.

Apparently, we have a "black box" that takes a string, "processes" it, and outputs a string with some substitutions. Unless you let us peek into that black box, we really cannot help. Is this a LabVIEW subVI using standard primitives? Who wrote it? 

[NathanTaub]

Apologies for taking so long to see your response. 

I meant any time these symbols pass through any string wire in a VI, they are corrupted when they come back out, even if you just wire a string control directly to a string indicator, unless UseUnicode is enabled. UseUnicode has the unfortunate side effect of breaking up every 8-bit character into a null character followed by the original character, which stops the XML parser from working. I already tried the Unicode Tools addon to compensate for this without success. 

[rolfk]

A wire does no transformations at all! But LabVIEW strings consists of 8 bit characters according to the codepage of your local language. If you interface to .Net functions they use by default Unicode. Your 8-bit local codepage does not have characters for these Unicode codepoints. So LabVIEW/.Net does some conversion when returning the string to LabVIEW. My bet is .Net here, LabVIEW uses the default Windows conversion function that replaces all unconvertible characters to a question mark.

The Unicode tools is so far a stop gap only, which can work in some cases but this conversion issue likely happens before these tools can even get in action. NI has however done work in this area in recent versions, just not to the point where it is a fully working feature. So trying with the latest version MAY show improved behavior when you enable Unicode support. But no guarantees yet! 

[Kyle97330]

---

@NathanTaub wrote:

Apologies for taking so long to see your response. 

I meant any time these symbols pass through any string wire in a VI, they are corrupted when they come back out, even if you just wire a string control directly to a string indicator, unless UseUnicode is enabled. UseUnicode has the unfortunate side effect of breaking up every 8-bit character into a null character followed by the original character, which stops the XML parser from working. I already tried the Unicode Tools addon to compensate for this without success. 

---

This is false and if you run the following code it can prove it:

Now, I will grant you that LabVIEW's support for Unicode is a bit lacking, and it's .NET interfacing *might* be related to the problem you are having, but since you have yet to show any ACTUAL details, we can't see what you're doing and offer suggestions for workarounds.

I would start by showing what sort of LabVIEW code or external code you are using that is looking for "≤" and "≥" symbols to begin with.  It seems like a bonkers way to set up code in the first place though, but maybe you have your reasons...

[Andrey_Dmitriev]

---

@Kyle97330 wrote: 

Now, I will grant you that LabVIEW's support for Unicode is a bit lacking, and it's .NET interfacing *might* be related to the problem...

---

It seems to be not so bad in this particular case, I checked this as shown below: