Several years back I had an internal engineer work on a vi that would uncorrupt the strings- since I wan able to roll back to an uncorrupted version I didnt test this too much. It essentially changed strings back from unicode in the vi, involving scripting and a private method. This tool should be tested by ni and published if possible to resolve the issue of font corruption. I will see if I can track down this email from ni to see if I am allowed to distibute the tool they put together.
If a tool was avaliable then ni could solve this issue until they can get the source of the problem fixed (since it is very rare and random in nature this could take a while.
Hello...Here's my latest VI to manually uncorrupt the strings one by one. This VI reads from the clipboard
and pastes to the clipboard. I run it "continuously" while I go through my code. I highlight the corrupted
string, press Control-C, and then press Control-V immediately. Then I move to the next string.
I attached it as an image because it's so fast to write and to avoid issues of conversion between LabVIEW versions.
There is still an issue I don't understand regarding which font style and size is encoded in the pasted string.
Sometimes it updates my font to MS Sans Serif 13 and sometimes it leaves it
as Application Font (vulnerable to corruption again). Maybe it depends on which font was used
in a previous edit in the program.
I have found that it does not fix the corrupted "True" and "False" strings in the selector of my case structures.
It also does not fix the text under a configurable DAQmx functions in my VI that indicates what the configuration
is. This VI is provided with no warranty of any kind. Use at your own risk. Hopefully it will be of use to someone.
I'm still eager to see if a batch VI could become available (thanks, Paul, for looking into whether your company
is willing to share its tool).
I'm glad you were able to create a VI for a temporary, yet understandably time-consuming fix. Here is a Knowledge Base article that talks a bit about such font issues. Finally, LabVIEW 8.5 is tecnically not officially supported on Windows 7 (compatibility table), but even though it's not officially supported, many customers have been able to install and run pre-2009 versions without issue. Have you tried running this VI while in XP mode?
Hi Deborah Y,
Thanks for responding to my post. While the references you cite do pertain to fonts in LabVIEW,
they do not pertain to the issue discussed in this thread. Others experiencing this issue are using
"compatible" versions and OSs. Therefore, I think NI's customers deserve that NI pay attention to
tracking down and fixing this very-costly bug. Yes, I'm running in XP-compatibility mode.
Do you have a previous version of your code saved from before all the characters changed (in an older version of LabVIEW or version 8.5)? If so, are you able to repeatabley get the characters to change to gibberish? If so, our R & D team would love to get a hold of that. The problem with this issue is that once it happens, a flag is set that will follow the object and cannot be reset, making the issue difficult to replicate. If you are comfortable posting your code here, we will do everything we can to help, and hopefully get it scrubbed and back to you quickly. If you really would like to get this issue resolved quickly one option you have would be to try signing up for free a 30 day service contract trial and call in since you mentioned your customer will be there Thursday. Regardless if you can post your code we'll do what we can to get a solution for you.
I have a previous version before the corruption event, but it doesn't contain the latest
features; else I would have reverted to it. I have not tested it to see if it corrupts. I am
not willing to post it because it has a lot of IP in it. I have now fixed almost all the
controls and indicators and about half the corrupted items in the block diagram. Now
the labels, constants, and comments in the block diagram that I fixed yesterday have shrunk in
size so that they do not show all the text in them. It's another tedious task to go through
and resize them all again. And I can't resize the numerical constants; the only thing I
can do is replace them - what a pain!
The tool I have was writen with an AE I had been working with, it is locked in 8.6. I will try to contact the original engineer.
NI or the community needs a tool to uncorrupt, and it is doable with a recursive script that itterates over the text on a vi (there are several places for the text to be corrupted) and un unicode the text (private properity but can be accessed with the correct ini settings). For several yesrs this problem has been approached from several dirrections but never really solved.
NI is there a central contact that we can use to help solve this problem?
Also, USE SCC, I use TortisSVN it is free and works with LabVIEW (yes thare are many choices here I jsut list the one I use), you can easily rollback, I submit new revisions prior to a build then I can not be burned by this bug.
Again, this is all included under CAR#185890, and since 'scrubbing' the VI involves some internal changes, we don't readily publish these but invite customers to contact us on a case by case basis as Jon S. mentioned. We definitely appreciate your patience any and all new associated details in order to get the best fix possible for this issue.
I think I found a workaround to this problem.
I had the same problem with my distributed system manager being in chinese after upgrading to 2010 SP1. I also couldnt run my exe files because of a run-time language problem. I had to rebuild all of them.
What I did was to remove the "ChineseS" folder from Shared\LabVIEW Run-Time\2010. Then my DM was in french. I removed the french, it became german. I then realised that the english folder was missing a file: lvapp.rsc.
I copied the french one into the english folder and it is now working properly again. Distributed Manager is in english and the exe files are working again.
Hope this can help you guys.
CAR 202900 actually has an easier workaround and it is documented in the Known Issues List.
Workaround: Go to <NIDIR>\Shared\LabVIEW Run-Time\2010\English. There should be a temporary file named something like "TBMAE0D.tmp". Also, lvapp.rsc should be missing. Rename this temporary file lvapp.rsc.
If this doesn't work a repair of LabVIEW will put the correct lvapp.rsc in the correct place.