Why does my LabVIEW occasionally display in Chinese?

[falkpl]

I have been through this situation (I have several posts on it) and know it is verry frustrating.  From what I know yes it has to do with

1.   ascii interperated as unicode (this is why changing the font does not matter). 

2.  It is almost always triggered by a build or some project operation.

3.  If you see it close the project without saving otherwise your effected fonts (usually application fonts) string constants are hosed (block diagrams, default strings, lables ...)

4.  This is rare and most internal engineers dont know about it you have to use labview alot to see it (I have used it daily for 15 years and have seen it about 4-5 times.

5.  It is possible to uncorrupt vis if needed but it involves a private method of strings to switch unicode back.

-  one of my old posts references an internal engineer who worked with me on this.

6.  Will most often happen on the day of a major deadline.

7..  IDEA SUGGESTION - Please fix this problem  it has been around since labview 8.0 and can cause major headaches.  Source code control is your best friend in this situation.

[Roy_F]

I've requested a CAR be filed for this problem. The CAR number will be posted here when done.

Roy

[blawson]

I just had LV itself get unicoded.  LV2010f2-32 on win7-64

here's a screenshot of the build specs dialog where I first noticed it.  Doesn't appear to affect the project I'm working on, though I haven't checked it thoroughly.

so, do I need to reinstall LV?

[JackDunaway]

---

@blawson wrote:

so, do I need to reinstall LV?

---

No! Just restart.

[falkpl]

My original fear is that my vi was outsourced.

[blawson]

came back in this morning and no change, with a shutdown and reboot in the meantime.

[JackDunaway]

Barrett, at any point did you have "UseUnicode=True" in your LabVIEW.ini file?

A colleague mentioned he has been able to fix "permanently Unicoded" diagrams/panels in our own code by traversing all FP/BD references and setting the "InterpretAsUnicode" flag to False. This is what I would expect would be required for the parts of the Unicoded IDE written in LabVIEW, but since most of these panels are locked, this is probably not an option.

Can you give any more information on what you've tried? One option is to call NI support, but your mileage may vary since Unicode is not officially supported by NI.

[blawson]

I've never turned unicode on.  I did search the project file for "unicode" and there are some vi.lib dependencies that do unicode conversion for the registry VIs.   I opened one of them in the hierarchy and got chinese characters throughout the hierarchy window *and* in the VIs that I opened from the hierarchy (it was dependent through RGTK).

Then I closed those windows, and went to the files view of the project and looked at the dependency tree structure.  After that, no more unicode.

What bothers me here is that it's not happening to my code, it's happening to parts of my LabVIEW installation.

[JackDunaway]

---

@blawson wrote:

What bothers me here is that it's not happening to my code, it's happening to parts of my LabVIEW installation.

---

I have also had the IDE get Unicoded, but nothing a restart of LabVIEW could not fix. Nothing was ever permanently Unicoded.

---

@blawson wrote:

Then I closed those windows, and went to the files view of the project and looked at the dependency tree structure.  After that, no more unicode.

---

Glad you fixed it and there's no permanent damage. Reinstallation is definitely an undesirable solution.

[tst]

---

@JackDunaway wrote:

A colleague mentioned he has been able to fix "permanently Unicoded" diagrams/panels in our own code by traversing all FP/BD references and setting the "InterpretAsUnicode" flag to False.

---

Looking at the example I posted above, it looks like this is definitely the case - the property is set on all the elements which are Unicoded. I guess that now someone just needs to dig into the code and see when this property is set to T (which, admittedly, may not be straight forward).