From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Unicode issues in LabVIEW 2022 Q3
Hi,
We are experiencing an odd and very annoying behaviour on our front panels which seems to be tied to LabVIEW 2022. We develop front panels in both English and Hungarian and the latter gives us a lot of headaches as character we type on the front panel changes everytime to something unreadable.
Hungarian has more letters in its alphabet and LV seems to have problems with "ő" and "ű" (the rest seems to work fine). To give you an example:
As you see the letter "ő" appears as a two byte thingy in hex view, which is supper odd. If I save this VI, close it and reload then my texts change to:
Now if I select the "Q" and overwrite it with an "ő" then:
I've tried to educate myself on the forums and I have found that this is an issue with unicode vs. ASCII, which seems to be true as if I replace the 5101 with F5 (before its changes to chinese) then the control will display "Levegő" properly and it wont change after reloading the VI.
I have tried using the UseUnicode=False 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.
What we developped several front panels with a Hungarian front panel and never had such issues with earlier versions of LabVIEW (which we dont have at this company). We have asked somebody who has both to try this font madness with both LV2021 and LV2022 and the result is that LV2022 shows the same behaviour while LV2021 works perfectly fine. We tried to exchange the labview.ini files if this is some sort of an ini file problem but its not, this changed nothing. Additionaly LV2021 allows to use "ő" in Labels while LV2022 doesnt (not if that we'd like to use, its just an extra info)
This suggests that something has changed in LV2022. Using the toolkit to convert unicode to ascii is the worst option I can think about as this means all FP strings need to be generated first with a labview VI and if we'd like to change a single character then we need to generate that strings again.
Mispelling "Levegő" to "Levego" or "Levegö" is a gross grammar error in Hungarian, which looks super sloppy and its just one word out of the many using "ő" and "ű".
So we are kinda bo... in bad situation. I'm wondering if anybody has an idea how can we get rid of this problem.
Thanks.
@1984 wrote:
Hi,
We are experiencing an odd and very annoying behaviour on our front panels which seems to be tied to LabVIEW 2022. We develop front panels in both English and Hungarian and the latter gives us a lot of headaches as character we type on the front panel changes everytime to something unreadable.
Hungarian has more letters in its alphabet and LV seems to have problems with "ő" and "ű" (the rest seems to work fine). To give you an example:
As you see the letter "ő" appears as a two byte thingy in hex view, which is supper odd. If I save this VI, close it and reload then my texts change to:
Now if I select the "Q" and overwrite it with an "ő" then:
I've tried to educate myself on the forums and I have found that this is an issue with unicode vs. ASCII, which seems to be true as if I replace the 5101 with F5 (before its changes to chinese) then the control will display "Levegő" properly and it wont change after reloading the VI.
I have tried using the UseUnicode=False 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.
What we developped several front panels with a Hungarian front panel and never had such issues with earlier versions of LabVIEW (which we dont have at this company). We have asked somebody who has both to try this font madness with both LV2021 and LV2022 and the result is that LV2022 shows the same behaviour while LV2021 works perfectly fine. We tried to exchange the labview.ini files if this is some sort of an ini file problem but its not, this changed nothing. Additionaly LV2021 allows to use "ő" in Labels while LV2022 doesnt (not if that we'd like to use, its just an extra info)
This suggests that something has changed in LV2022. Using the toolkit to convert unicode to ascii is the worst option I can think about as this means all FP strings need to be generated first with a labview VI and if we'd like to change a single character then we need to generate that strings again.
Mispelling "Levegő" to "Levego" or "Levegö" is a gross grammar error in Hungarian, which looks super sloppy and its just one word out of the many using "ő" and "ű".
So we are kinda bo... in bad situation. I'm wondering if anybody has an idea how can we get rid of this problem.
Thanks.
I think you are supposed to set that to "TRUE"? (It seems logical that setting "UseUnicode=False" would make it NOT use Unicode.)
@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.
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:
@rolfk wrote:
Unicode support in LabVIEW is still experimental. Use of that is at your own risk!
Thanks for stating this like it would be a wisdom. Yeah, I use it at my own risk! The problem - as I've explained above - is that worked before but in LV2022 it is engineered ambitiously to a level in which I can't make front panels in Hungarian (which we had no problems with before). Quite funny that a $5000+ software bundle can't handle an issue which was solved literally decades ago in other languages. NI should advertise that they made their IDE worse than it was before.
@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:
Thats cool (didnt know about this) but unfortunately not a solution to our problem.
@1984 wrote:
@rolfk wrote:
Unicode support in LabVIEW is still experimental. Use of that is at your own risk!
Thanks for stating this like it would be a wisdom. Yeah, I use it at my own risk! The problem - as I've explained above - is that worked before but in LV2022 it is engineered ambitiously to a level in which I can't make front panels in Hungarian (which we had no problems with before).
The problem is that this Unicode support has been VERY experimental. It was not a clean solution but kind of hacked into and only works for Windows.
Unicode support is on the list of things to work on for a future release and someone likely did do just that but not to a point where it was anything to be released at all. However such work can and will affect the existing unofficial Unicode support. And since it was an unreleased feature anyhow, breakage of it is not something that is considered a show stopper for a release. Unreleased features can and will change, or they might go away, or get replaced by something entirely different. The fact that it changed somehow means that someone worked on it in some way.
It's also very likely that once it is released (it's really on the todo list to be released in one of the next releases, although maybe not THE next) it will not work exactly as how you did it in the past with this ini file setting and you will probably have to redo multiple things again.
