Changes to Unicode support in LabVIEW 8.6

[Evgeny_Sviridov]

The same situation with Russian. Unfortunately LabVIEW 8.6 has a lot of bugs. It seems to me that NI decreases quality of their products both hardware and software, time-to-market is a high priority. At NI Week-08 I had a discussion with one of the leaders of NI. I told him about problem when products development and testing time becomes shorter. As a result customers and system integrators have a lot of troubles. I understand the market rules but NI's quality have to be NI's quality again!..

It seems to me It is impossible to simple avoid unicode support troubles in LV 8.6. Neither regional settings nor code page translation modification can solve the task. The only way is "Copy-Paste" method which was used under LV 8.6 since August 5 8-). So I am waiting for patch. At present time we use LV 8.5/8.5.1 for software development and student teaching.

Regards,

Evgeny

[Intaris]

How about introducing a two-tier approach.  Define some versions as LTS (Long Term Support) which are guaranteed bugfixes for a few years.

Then have incremental "feature upgrades" until the next LTS version.

I have a current project with a bug which won't get fixed because the problem isn't in 8.6.  I need to use 8.2 because the customer wants it that way.  I am limited by these known bugs (and have to remove functionality because of it).  Fixes would be very nice, especially when the bugs can be reproduced and located.  I can settle for some features less if NI will back up their systems with longer-term bugfixing.

Shane.

[tst]

I also found out now that even if the strings are displayed using the Hebrew characters, doing any kind of operation on them (e.g. concatenating) results in gibberish. This is practically a show stopper for using 8.6 with Hebrew interfaces.

As a side issue, there's a small bug which has been in LV for a long time and keeps annoying me. Whenever I switch to Hebrew input, Ctrl-W stops working and will only resume working after restarting LabVIEW. Other shortcuts are not affected.

w is 119 ASCII.

In Hebrew, the W key produces an apostrophe ('), which is 39 ASCII.

Before switching to Hebrew, Ctrl+W always results in 119 (I used the Key Down? event to check).

After switching, Ctrl+W always results in 39, even after switching back to English.

[Babel]

To all,

We have reproduced the problem with Hebrew, Russian and most likely all languages that are not in the Windows 1252 codepage or that do not use an IME (asian languages) for input.  As I wrote before, this defect was filed to LabVIEW R&D with high severity and they are currently evaluating the issue. When I have more information, I'll post it on this thread.

Thank you.

-Michel Farhi

Localization Manager

[Nitin_T]

Hi Everybody,

We identified the source of the problem and have released a patch (LabVIEW 8.6f1) to address it. The patch is available for free on the Drivers and Updates Page. More information and installation instructions for the patch can be found in the readme. Thank you for reporting this issue.

[tst]

Excellent!

I'll download it in a couple of days. Thanks.

[tst]

OK, it seems to work fine* in Hebrew. Please thank the relevant developers and whoever made the decision to issue a patch.

* Fine - like it worked before, not like it how it should actually work. In order to properly support right to left languages, NI would have to add quite a lot of code to handle all kinds of things.

A couple of examples of the current problems in Hebrew - selecting something in a text treats the text as being L2R, so that you actually need to place the cursor on another part of the text; Placing any non-alphabet character in the text causes it to appear on the right side of the text instead of the left and the only way to get it to the left is either to add an alphabet char after it or to place the character at the beginning of the string. This gets complicated if you have multiple lines or such chars at both the beginning and the end (e.g. a "1" at the beginning and a period at the end). I'm not even talking about letting actual users do text input, which requires using ActiveX controls if you don't want to get support calls for the rest of your life.

[Evgeny_Sviridov]

Thanks to NI team. It works! Both keyboard input and string fungtions work correctly.

Regards,

Evgeny Sviridov.

[DjDaveNI]

Hello Everyone,

Thanks for the feedback. NI strives to provide the best products possible. Post back to this forum if the issues persist. Thanks!