LabVIEW
Turkish special characters displayed incorrectly
Solved!
I had same issue long time ago. The following line had solved my issue at that time.
UseUnicode=True
Now I have an interesting issue as in the picture.
Turkish special characters
For a while I have been developing applications in English language. So I am not sure if this is totally a new issue or it was there for a while but I did not notice. I think this is totally a new because I am sure somehow I have noticed this. And when I check another computer everything seems fine.
No issue
I can write special characters but when I run the code they are displayed incorrectly.
Labview 2021
Labview 2022 Q3
Windows 11
What is your local language setting in Windows in these cases? LabVIEW Unicode support is not even experimental but at best alpha state. It means it has been added with minimal testing but never formalized and fully tested. It was considered a too hard problem to tackle at that time and abandoned but never removed from the code base.
If your local language setting is set to Turkish, LabVIEW will actually support Turkish characters even without using Unicode since it uses the local region settings by default. Now if your constant where you enter the Turkish characters is not set to be Unicode explicitly too, the string entered will simply be the ANSI string using the current Windows codepage, hence the codepage 1254 characters. If you then change the local language settings the bytes in this constant will stay the same but display different characters. You then wire this byte stream to a control which is told to interpret the bytes as Unicode characters. And bam it goes wrong, since the codepage 1254 byte codes are simply interpreted as a Unicode byte stream and that will surely result in something completely different, usually chances are pretty high that you will see at least some Chinese characters then.
You must make sure that all strings that you want to display Unicode are also set to be Unicode. You can not wire different types of string encodings together as the LabVIEW Unicode support never has been finalized to deal with such encoding mismatches and automagically do the right thing. The attribute, if the string is considered Unicode or not is simply part of the actual control or constant, but not part of the actual byte stream data that is flowing through your wire, so if the source and sink of such a wire do not match in what the bytes should mean it simply goes wrong.
It's similar to how the hex, decimal and octal display options work. The indicator displaying an integer value has no idea if the source from where this integer comes used hex, octal or decimal display mode and doesn't care about that. It sees an integer and formats the display according to its own local setting and that's it. A string is simply a sequence of bytes and by default is interpreted according to the ANSI codepage set in Windows as local language. If you enable the Unicode attribute the control or indicator simply interpretes the bytes as Unicode and that's it. But unlike with the display format of integers, string display encoding is a lot more complicated and there are many corner cases and complications that are very difficult to handle properly and the people who have worked on that in LabVIEW apparently threw their hands in the air at some point and probably quit their job.
The main problem is that LabVIEW started out with treating strings as simply a bit of syntactic sugar around a byte stream. Other languages actually did the same such as Python where strings were initially also just byte streams instead of its own distinctive first class datatype citizen. Python at some point did a pretty radical cut and decided to make strings simply always Unicode, and that was a painful transition for many Python programmers. The LabVIEW developers tried to avoid that and since the main LabVIEW use was in instrument control and measurement applications they could get away for a long time by simply deferring the tackling of the problem to a future version almost indefinitely. Now it is a bit late to make the right choices and with the NI focus shifting away from LabVIEW, things don't get easier either.
Most likely your constant is NOT set to be Unicode enabled. Since you run on a Turkish system that is perfectly fine as you use the codepage 1254 in that case and LabVIEW simply uses the Windows ANSI display functionality that translates the codepage 1254 bytes under the hood into the correct Windows 16 bit Unicode sequence (UTF16LE to be precise) and then displays it on the screen.
Now you pass this codepage 1254 byte stream to an indicator that you told to treat the incoming bytes as Unicode (in this case Unicode means UTF8 since LabVIEW is multiplatform and UTF16LE support is not available on many non-Windows platforms). That is an encoding mismatch. Your indicator has no idea what encoding the bytes in that pink wire are in and you told it "Sure believe me, it is Unicode (UTF8)", but it is NOT, it is codepage 1254. LabVIEW has no official encoding translation support either but the Unicode knowledge base article from where you got that INI file setting also has two functions to convert between the current codepage to Unicode UTF8 and vice versa. As mentioned, the problem is complicated and you need to make sure you get source and sink of a string to agree on the encoding or do according conversion yourself. LabVIEW is not going to hold your hands here and doesn't do these things automagically for you!
And changing your local settings to English won't solve anything, it will just make your constant display now as gibberish too, since the bytes you entered there before are now interpreted to be codepage 1252 (Western Europe) or maybe 1250 (Central Europe)
@Zafer.Depe wrote:
@rolfk wrote:
Most likely your constant is NOT set to be Unicode enabled.
True,
I had no issue before. I am sharing Labview.ini file. Do you have any further suggestion how to fix this?
No! Considering that the constant and the indicator have NOT the same encoding setting, this is what I would expect. Why it would have worked like this before I don't know, it definitely shouldn't have! Sorry.
After I removed the line
UseUnicode=Truefrom Labview.ini file, one part of the issue is solved. Controls and constants seems working fine. Now I am getting nonsense charachters only at the title of the front panels. Also .Net components have the same effect.
The problem seems solved. It was not a Labview issue but Windows 11 Unicode UTF-8 support to worldwide language problem.
I unclicked this option and problem is solved.
