08-26-2014 10:58 AM - edited 08-26-2014 11:12 AM
Hi, LabVIEWers:
If you've been following some of my posts here (I have no idea why you would, but just in case), you know that a project I am working on is a translation of things from English to unicode. It's been working fabulous so far, except for one thing.
It seems that 不 is consistently showing up as 上 in any text box, caption, etc, etc, but only if I read it from a text file! It doesn't matter what position it's in, and I tried saving it in notepad (unicode option), notepad ++ (encode in UCS-2 little-endian) and Word (other encoding - Unicode) but it doesn't make a difference. And when I copy the wrong character and paste it, it really IS the wrong character, like it magically got transformed.
If I paste the right character into a any kind of text box, it works fine. Furthermore, I can wire that text box to anything that accepts a string and it shows up correctly there, too.
Here's ther weird thing:
As far as I can tell, that's the only character I am having trouble with!!!
Anyone have any ideas?
Thanks!
Oops, LV 2009 SP1.
Solved! Go to Solution.
08-26-2014 11:38 AM
The ugly workaround I installed was to do a simple substitution, but obviously that won't work if the text is SUPPOSED to be 上!
The other workaround was to eliminate the 不 from the text file and and insert the 不 where it belongs in the code.
Each way has its pros and cons. Any comments?
08-26-2014 12:23 PM - edited 08-26-2014 12:25 PM
I see that 上 sits on bit 10 and 不 at 13 on the same word. Do you think they accidentally both got mapped to 10 by whoever coded the unicode support? You know, cut and paste '10' for mappings '10' - '15' and then forgot to change one of them?
Or do you think it's silly to assume that someone did it by hand?
08-26-2014 12:39 PM - edited 08-26-2014 12:41 PM
oops
08-26-2014 01:38 PM
It was a case of "stupid me." Disabling "Convert EOL" on the read from text file makes it work fine. I got to this point by remembering about disabling termination characters when dealing with binary data. That triggered the thought that the same kind of thing could be happening here.
08-26-2014 01:43 PM
billko,
This is off topic but, how to you deal with the Run-Time Menu for unicode?
08-26-2014 01:57 PM
@J-M wrote:
billko,
This is off topic but, how to you deal with the Run-Time Menu for unicode?
Tell you the truth, I haven't gotten that far yet! If I find a solution, I'll let you know. 😄
08-26-2014 01:58 PM
Dec 10 is linefeed and dec 13 is carriage return. Are you sure you disabled Convert EOL on the read file function? I'm not sure how you read in the Unicode strings but if you use Read Text File there is a right popup option to have LabVIEW do some automatic translation. Does Read File deal with Unicode or are you doing something yourself there? Either it does not and then of course does ASCI replacement or if it does the code for Convert EOL does not correctly treat Unicode characters.
08-26-2014 01:58 PM
The author of the LabVIEW Unicode Programming Tools should update his code - he didn't catch it, either!
08-26-2014 02:10 PM
You are absolutely correct. I shoudl've recognized that. Fortunately I had other experiences which led me to the same conclusion after having gone down a different path.