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
LV text rendering, MBCS, OS, Unicode
Dear LV users,
I have the problem in understanding how LV is rendering strings.
So far I understand (I hope I do) that Windows uses unicode UTF16. In LV we do not have Unicode support and (we have some private functions but using them is too much pain) uses MBCS so we need codepage to tell how string needs to be rendered. In Windows we can set system locale that will tell non Unicode apps how to render strings?
Assuming all that i have a problem understanding why this is displayed:
It should display exactly what is on this codepage? If not can someone explain why it shows this results and some random digits at the end?
Unicode strings can be converted to multibyte based on given codepage by using
WideCharToMultiByte and MultiByteToWideChar.
Assuming I have something written in russian/chinese (Unicode) we can convert that to MBCS based on codepage and display correctly for valid codepage in the system?
I have looked at LV error files and they are stored in utf8 for xml files, so some sort of conversion must occur inside LV to correctly display this data?
txt encoding of error files varies (at least that is what notepad++ is saying), for Chinese txt we have GB2312, when system locale is set to China I assume this coding will be used to render text in LV?
Just a tip: each application can have it's own locale. Before Windows 10 you could use AppLocale, now you need pooi.moe/Locale-Emulator/ to start an application with a different locale. Makes switching back and forth a bit easier!
Will have a look at the problem. I think the table shows CP indices VS character. But LV needs MBCS characters, not CP indices. So you need to convert (escape) some of those CP indices. Some indices will need a two byte representation... Can't find an exact algorithm, but I think something like that must be happening.
Search LabVIEW like a graph! It's weird:
WideCharToMultiByte converts 3E04 to EE, as expected.
But MultiByteToWideChar converts EE to 3E. To get 3E04, we need to enter 3Exx, where xx can be anything
I'm sure I figured it out before... Drawing blanks now...
It seems that conversion works file between UTF16 and MBCS for provided codepage. What is the difference between CP and actual MBCS data? I can not find that and my assumption was they are the same thing 
So now having proper MBCS data that should be rendered using default system codepage from regional settings.
But when I change from EN to Russian Cyrillic characters are not displayed correctly, I have tried other fonts but it is still the same.
Do You have any idea what might be the problem or am I doing something wrong here?
@pawhan11 wrote:
It seems that conversion works file between UTF16 and MBCS for provided codepage. What is the difference between CP and actual MBCS data? I can not find that and my assumption was they are the same thing
Yes, that was just a hunch, based on other CP's that do use escape characters to extend characters (more then 256). But for 1251, I think the bytes should convert to Unicode using the CP in a trivial way. That is, the CP should function as a look up table.
pawhan11 wrote:So now having proper MBCS data that should be rendered using default system codepage from regional settings.
I think it should. But it doesn't.
@pawhan11 wrote:
But when I change from EN to Russian Cyrillic characters are not displayed correctly, I have tried other fonts but it is still the same.
Do You have any idea what might be the problem or am I doing something wrong here?
No ideas. I like to know myself, but I tried and am seeing what you see. I tried MS API's and that shows weird behaviour as well.
So, I'm out of ideas... Not only out of ideas about what's going on, but also out of ideas to further investigate. It just seems to "not work properly"...
@pawhan11 wrote:
@Thanks, @Yameda for the reply.
I have seen this thread before starting this topic. From what I have seen displaying strings as Unicode is bugged/not all captions/fields are supported and using that will be overcomplex to my opinion. I am trying to approach that from a different angle if that is possible before LV NXG will be mature enough to be used.
Worst case scenario: You'll have to use .NET functions to draw pictures to show it correctly. Hopefully there's some better way to do it. 🙂
/Y
