Unicode issues in LabVIEW 2022 Q3

[paul_a_cardinale]

---

@paul_a_cardinale wrote:

Text has an "Interpret as Unicode" bit that is settable character-by-character (as a font is).  If not all characters are set as Unicode, you can get strange results.  Try this:

---

Some might prefer something like this:

..

[1984]

---

@zou wrote:

Have you read this NI's Unicode document:

https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Unicode-Programming-Tools/ta-p/3493021?pro...

---

I did, but that wont solve anything for us, merely explains why do we see what we see. And again, we had no issues like this with LV2021 and LV2020 so something has changed to the wrong direction in LV2022 and based on the comments above it seems that there is no escape from that. It would be a huge hassle to generate all the texts, captions, comments etc as ASCII with an actual labview code instead of just typing them.

[wiebe@CARYA]

---

@billko wrote:

---

@1984 wrote:

Ooops, sorry I mistyped this probably because I had my ini file open in notepad++. (and it is False now)

Correctly:

I have tried using the UseUnicode=True in the LabVIEW.ini (and to force unicode on strings) but that didnt help moreover I've seen that the entire front panel switched characters to Chinese.

It seems with both True and False we have major issues, actually turning it True doesnt seem to solve anything.

---

Now that makes sense.  😄  I think Unicode became an official "thing" in one of the newer versions.  Could this possibly be a regression somehow related to that?  Sorry, I know this doesn't really help you.

---

AFAIK It's on the roadmap, but not an official thing yet (although unofficially a *%$# thing).

[ThomasHenkel]

Never mix Unicode and ASCII in your labels, string constants or captions - that can crash LabVIEW!

LabVIEW uses UTF16 little endian, that means your ASCII character "L" is in Unicode hex "4C00". For "Levegő" insert 0-Bytes after each ASCII character: "4C00 6500 7600 6500 6700 5101"

To set text or captions to Unicode, use the code from paul_a_cardinale

With a few exceptions, Unicode works quite well in LabView32. We have applications that can be switched between Russian, Polish and Chinese. It's a lot of work once, but it works.

Remarks:
- of course set UseUnicode=True
- some elements do not allow Unicode, e.g. the selectable elements of a dropdown box
- some elements can display unicode if an unicode text was manually copied into it in the IDE once, e.g. captions of buttons and tab pages

- some elements need the BOM for UTF16LE: 0xFF FE, e.g. cells of a table

Disclaimer:

We use LabVIEW 2020 32bit, so I don't know what may have changed in the newer versions.

[Attila.telek.ob]

I think we can say based on the followings that LabVIEW 2022 Q3 has a bug:
I installed LabVIEW 2022 and LabVIEW 2020 on a machine running Hungarian Windows 11.
When editing a label in both versions, I typed a Hungarian ‘ő’ character.
The result: 2022 wants to insert it as a Unicode character, while 2020 interprets it correctly (ISO 8859-2).
    

[1984]

---

Disclaimer:

We use LabVIEW 2020 32bit, so I don't know what may have changed in the newer versions.

---

As mentioned before we dont have this problem with earlier versions of labview.

[billko]

---

@1984 wrote:

---

Disclaimer:

We use LabVIEW 2020 32bit, so I don't know what may have changed in the newer versions.

---

As mentioned before we dont have this problem with earlier versions of labview.

---

My experience with official support for Unicode is that there isn't any.  But they do try to help.  It probably won't become a bug, but I'm guessing it will be accounted for in the official release - whenever that is.

[wiebe@CARYA]

Do you actually need Unicode for this problem?

If you set the legacy code page support to your local code page, you should be able to use the default encoding (that uses this code page) to get all the Hungarian characters you want.

I did a English\Czech\Chinese translation this way. By switching the text and the local code page, the entire application can translate between English\Czech\Chinese that way. Storage of the text is tricky though...

[rolfk]

---

wiebe@CARYA wrote:

I did a English\Czech\Chinese translation this way. By switching the text and the local code page, the entire application can translate between English\Czech\Chinese that way. Storage of the text is tricky though...

---

It depends. If you talk about Import/Export (reading in and writing text files for instance) you should be fine by using the ASCII to Unicode functions and vv. in that KnowledgeBase article. Since your locale is set to a specific code page, those functions will automatically convert to and from that, and the external Unicode format is always the same.

Of course you need to define your interfaces and consistently handle the same conversion on the input and output direction on each interface.

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

I did a English\Czech\Chinese translation this way. By switching the text and the local code page, the entire application can translate between English\Czech\Chinese that way. Storage of the text is tricky though...

---

It depends. If you talk about Import/Export (reading in and writing text files for instance) you should be fine by using the ASCII to Unicode functions and vv. in that KnowledgeBase article. Since your locale is set to a specific code page, those functions will automatically convert to and from that, and the external Unicode format is always the same.

Of course you need to define your interfaces and consistently handle the same conversion on the input and output direction on each interface.

---

I usually figure out the details as I go, but IIRC you run into problems easily if you let the customer make files (for instance in notepad), and then assume you can read them in LabVIEW. if the ini files are saved as Unicode, you have to convert it in either Notepad or in LabVIEW.

I usually ask for screenshots to complement the stored text, as it all looks Chinese to me.

Testing is another complication. You can't simply switch language, you have to restart your application with the other code page configured (or use an app that starts your application\LabVIEW with the code page).

But for me this worked (better than Unicode).