LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unicode issues in LabVIEW 2022 Q3


wiebe@CARYA wrote:

@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).


This will allow you to access Unicode config files.

Message 21 of 35
(1,405 Views)

It was true for all the LabVIEW versions prior 2022.

LV2022 wants to insert an unicode 'ő' instead of the legacy 1 byte version regardless the labview.ini setting. You cannot recognise it immediatly just when exit labview then reopen it. Next time it displays a bad interpretation.

So I still say that it is a bug in this version.

Unicode handling is a different thing, it is documented and we can use it. But here I am not using any unicode files, texts, settings I am using legacy environment and just pressing a key.

It was fine before LV2022.

0 Kudos
Message 22 of 35
(1,376 Views)

@Attila.telek.ob wrote:

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).
lv2022.png    lv2020.png


Same here in a brand new install of LabVIEW 2023 Q3. Besides of that all the cyrillic texts are displayed gibberish, when reopening the VI.

2023-07-27_20-32-31.jpg

They are OK when typing at first time though. Both LabVIEW 2022 Q3 Known Issues and LabVIEW 2023 Q3 Known Issues do not mention this.

0 Kudos
Message 23 of 35
(1,261 Views)

The problem has more serious consequences than I thought. The error is present even in the built application. So if the end user presses the affected keys, the program will work incorrectly or even crash depending on where they pressed the button.

Therefore, LabVIEW cannot be used in Hungarian-speaking areas from version 2022 onwards. I suspect that this is also true in many other countries. 

Fortunately, you have figured out a workaround with AutoHotKey: 

https://github.com/telattila/LabVIEW_UnicodeBugFix.git

0 Kudos
Message 24 of 35
(1,233 Views)

In the Test Workflow Roadmap – 2023 Q1 document there's "Support for Unicode in the IDE" work planned for future development. It much looks like they have already started, but not finished it yet, hence its rawness. Maybe it's gonna be fixed with the upcoming patches, hard to say. I decided to keep my work LV instance at 2021 version until this issue gets resolved.

0 Kudos
Message 25 of 35
(1,183 Views)

There is a note in LV2023Q3 that they have fixed some unicode issues. Not ours though, the problems described above still exist in 2023Q3.

 

0 Kudos
Message 26 of 35
(1,169 Views)

I think, it could be related.

 

LabVIEW 2023 Q3 Bug Fixes 

Bug Number: 2331372

 

Description: LabVIEW Sometimes Crashes When Labels Contain a Mix of Unicode and Non-Unicode Characters

Workaround: There is currently no known workaround for this issue.

 

Details:

Reported Version: LabVIEW 2022 Q3

Resolved Version: LabVIEW 2023 Q3

Added: Jul 20, 2023

0 Kudos
Message 27 of 35
(1,113 Views)

@dadreamer wrote:

I think, it could be related.

 

LabVIEW 2023 Q3 Bug Fixes 

Bug Number: 2331372

 

Description: LabVIEW Sometimes Crashes When Labels Contain a Mix of Unicode and Non-Unicode Characters

Workaround: There is currently no known workaround for this issue.

 

Details:

Reported Version: LabVIEW 2021 SP1

Resolved Version: LabVIEW 2023 Q3

Added: Jul 20, 2023


Its probably somewhat related but unfortunately it doesnt solve our problem. I received the same info from an NI applications engineer. We tested LV2023Q3 and the problem is still there. It was reproducible by that NI AE and a bug (2484063) is filed. LV still crashes / displays random characters for some keypresses.

Message 28 of 35
(1,107 Views)

Don't use unicode in Labels. Captions are for language specific text for e.g. operators.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 29 of 35
(1,101 Views)

@Yamaeda wrote:

Don't use unicode in Labels. Captions are for language specific text for e.g. operators.


Its not just the labels. It everything which has text:

- string control values

- captions

- enum strings

- notes

 

etc

0 Kudos
Message 30 of 35
(1,093 Views)