Support Unicode

[JackDunaway]

Support unicode officially for all FP indicators and controls! Captions and string indicators can be "coaxed" into showing Unicode characters (among other controls/indicators), but trees and listboxes (among most others) cannot show Unicode.

Of course, this may have a small audience, but anyone who has developed a UI meant to be distributed to half a dozen language-speakers has probably fought the same Unicode battles and figured out the display "hacks" that we have.

[bseguin]

Seriously??? 2018 and still no support of Unicode in LabVIEW??? I am struggling to implement that. This is madness!!!! 50% of my time spent on development is in finding work around to support Unicode in my application. NXG is crap and not intended for full application development. PLEASE be serious NI... If you really are an international company, behave as one. Unicode is not a nice to have in 2018. IT IS A MUST. I really wish to talk directly to the R&D team leader or even replace that guy. Bug list that is there since forever and never be fixed. Where is the REAL Agile development while listening to your customer need? NXG is not a customer requirement. It is a bubble that some Marketing people pushes to you and do not represent the real need that 99.9% of LabVIEW developer need.

Benoit

[wiebe@CARYA]

Just let it all out...

[randol]

Unicode support is just one of many LabVIEW problems.  I no longer use LabVIEW for user interfaces.  If LabVIEW must be part of the application (increasingly not a requirement, many alternatives these days) then I compile as DLL.  C++ for user interface development with poedit for internationalization.  We are moving away from LabVIEW, too many problems with the IDE during development and no direct support anymore (you used to be able to talk to an application engineer and get things fixed, now timely support must be purchased).  I've seen this at companies that I have worked for when management neuters engineering's ability to tell marketing no.

[bergerdi]

Hey, stay calm.

It's just 1996 when Unicode 2.0 was finalized.

What do you think might happen in just a couple - say 23 - years? A fully implementation of a world wide standard? *laugh*

C'mon this is not to handle! It takes a long development and testing and hey... it finally got working as surprisingly integrated in the new Labview NXG that is a completely different type of product but isn't it nice to see it working there?

The grass is always greener on the other side of the fence. So be thankful for having solved this issue after such a long time.

No need to get mad 🙂

[ImreSzebelledi]

This is not completed at all as NXG is discontinued. I am having a hard time explaining the customer that I cannot provide him with two separate language because the the software I choose to develop in is stuck 25 years in the past. The not officially supported Useunicode flag in the ini file is causing all kind of problems like labview and built application crashes alike so it is not usable for me at all. 

[wiebe@CARYA]

First, I feel your pain.

Note though that even with no Unicode support at all you can support multiple languages, as long as the code page of the running application uses the code page for that language.

So an application can support Cyrillic, if Windows' "code page for legacy applications" (😑) is set to Cyrillic. The exact same application can support Chinese if the code page is set to Chinese. Of course all text needs to be updated, but Unicode support won't fix that.

It's just hard to use all Unicode characters at once. And testing is tricky.

It's something...

[ImreSzebelledi]

Unfortuantely the two language don't use the same codepage as for one operator it is hungarian and for an other it should be ukrainian. Windows used to have mode for starting an application in a certain locale but it is gone and it is not much of a help either becuase as you have stated it is just a pain when you store data using a certain codepage and it is just garbage when you switch to an other one. I have always thought that localisation is a really weak point of labview but damn it is just so frustrating, especially when NI just does not seem to care if you look at the date this idea was born. Saying "it is done" is the same thing as saying "it is done just because a completely other software supports it".

[randol]

http://utf8everywhere.org/

Please pass that link on to the NI engineers.  This is really not that hard of a problem to solve unless your source code is a complete mess.

[wiebe@CARYA]

In stead of applocale you can try Locale Emulator (SourceForge). It probably has more options as well... I can't vouge for it, haven't used it (or forgot I did).

There are some initiatives to get threads like this to be 'uncompleted'. Not sure why this one isn't reset, it might simply take some time.

I'm do know Unicode is a priority.

[Cepera]

My main need for Unicode is to be able to localize the UI - all of the UI, including graph labels, string controls, indicators that are parts of (nested) cluster controls,  decorations, etc. This means not just Unicode support, but also the ability to easily load a language from some table or XML file, or something similar (not necessarily on-the-fly: restarting the program after changing language selection is not a big deal). Our company has sold instruments 70+ countries, and not everyone is comfortable enough with the UI all in English.

Additionally, I would like to have support of user inputs, including filenames. String constants on BD are also needed. Rudimentary string processing would be nice to have (along the lines of "find/replace a substring"), although I don’t see an immediate need for it. I don't need UTF-8 support of SCPI over VISA.