Windows 7 Turkish Language Pack Free Download
Gro Bert
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.
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.
Thanks for explanation. I did not change windows local language settings. Moeroever I have only Turkish language installed on my computer. This behaviour is really weird. I have never met such kind of issue before. Years ago I had similar issue but it was a generic unicode support problem and "UseUnicode = True" feature was solved it.
This time I can write special characters without any issue. But when I run the code they are displayed incorrectly. I never chage local language when I try this. After then I installed English langguage support. But it is not solved. It appears when I run the VI is really weird.
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)
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.
from 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.
I then configured each project that I cared about in my solution (I ignored the unit test project) to enable code analysis using thisruleset file. Just go to the project properties and select the Code Analysis tab.
At some point, I reached the point where I was including a large number of rules and it made sense for me to invert the list so rather than listing all the rules I want to include, I only listed the ones I wanted to exclude.
One other thing I did was for really important rules where there were too many issues to fix in a timely manner, I would simply use Visual Studio to suppress all of them and commit that. At least that ensured that no new violations of the rule would be committed. That allowed me to fix the existing ones at my leisure.
@John great question. That's a rule I generally ignore unless I have some specific reason that requires it. It really depends on the application. For example, I ignore all the rules about COM because I don't care about COM interoperability. When that becomes a requirement, then maybe I'll turn them on.
There's a famous story about Ramazan aloban, who wrote to his friend (and probablty a girlfriend) Emin an SMS, that ws received with "sikisince" ("they are fucking you") instead of "sıkısınca" ("run out of arguments"). The result was: one murder, one suicide, three people are put in jail.
I thing the correct code would be to use "interesting".ToUpper () instead of "INTERESTING". But then again: your production example was probably a little different.
But it's all in the context. I once wrote an SMS-application for a Turkey's cell phone provider. Once we learned SMS messages with turkey's characters only can be like 40 characters (instead of 140), just used the ascii representation. To make sure we didn't run into ambiguities (like the one Rikki mentioned), we had the texts reviewed by some Turkey's speaking colleagues.
Too bad .NET does not have a standard method on strings for Unicode case folding. Adhering to the Unicode standard by using case FOLDING to compare strings in a case-insensetive way instead of introducing both an ordinal and invariant way of doing a case-insensitive will not wipe away all the differences between cultures, but it does implement a well-known and well-defined way of comparing strings without any regards to case. Notice that String.Normalize(NormalizationForm) IS part of the framework since .NET 2.0! Maybe it's time for a few extension methods on strings to fill in the gap ...
@Doeke: I think the right approach is to use input.Equals("interesting", StringComparison.OrdinalIgnoreCase);
@Nando: Well my ruleset turns off some rules I actually want turned on because we have too many warnings. I'll see if I can create one that's my ideal case. Also, it really depends on whether you're writing a library vs an app.
We ran in to this problem some years ago when deploying our product in Turkey. The problem occurred in our database queries. All tables/fields started with a capital letter, and of course some of those happened to start with an "I". But then some lazy programmers knew that the query parser (SQL in this case) wasn't case-sensitive, so a lot of queries were typed in lower-case only. These queries failed miserably and it was quite hard to find them all...
Hmm, previous comment was marked as spam.
This is actually an important problem which can cause many un-obvious side effects. For instance, see this entry on PHPs bug tracker: =18556. It will essentially break your whole codebase if you set the locale to tr_TR.
It's quite hard to find problems like this so raising the awareness of it is great.