04-17-2023 10:16 AM - edited 04-17-2023 10:17 AM
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.
04-18-2023 01:23 AM
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.
07-27-2023 10:40 AM
@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).
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.
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.
07-28-2023 02:56 AM
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:
08-08-2023 01:28 PM
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.
08-09-2023 03:28 AM
There is a note in LV2023Q3 that they have fixed some unicode issues. Not ours though, the problems described above still exist in 2023Q3.
08-25-2023 03:15 AM - edited 08-25-2023 03:21 AM
I think, it could be related.
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
08-25-2023 03:23 AM - edited 08-25-2023 03:24 AM
@dadreamer wrote:
I think, it could be related.
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.
08-25-2023 03:40 AM
Don't use unicode in Labels. Captions are for language specific text for e.g. operators.
08-25-2023 04:01 AM
@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