05-10-2012 12:55 PM
I frequently use Ctrl-F to search for instances of a given state name in my code, and I use Ctrl-G to walk through the findings. Yesterday, I did this and noticed that each time I hit Ctrl-G to go to the next instance, it was clearing my array of states. I have not been able to duplicate this exact behavior, but I have demonstrated similar behavior in the attached VI. Notice that it only occurs when the cluster is type defined.
I installed the LabVIEW 2011 SP1 f1 patch, but the problem persists.
Open the VI, press Ctrl-F, and type "abc". Then, continue hitting Ctrl-G to watch the behavior.
After search and iterating through instances of "abc" [Note: it actually took 2 trips through the instances for the mangling to be complete]:
Solved! Go to Solution.
05-10-2012 01:14 PM
Confirmed. Though I've seen this sort of odd behaviour on previous versions as well. Always with enums.
05-10-2012 01:43 PM - edited 05-10-2012 01:46 PM
Spoke to application engineering and the AE is going to create and post a CAR #. This bug has potential to totally hose applications if the user doesn't instantly realize what is happening. There is no way to know what state names were changed, so you would basically have to go through your entire application and check the transition logic. Yikes.
The AE agreed and is filing it as a show stopper.
05-10-2012 02:01 PM
Hello All,
Car 354380 was filed today regarding this issue
06-11-2012 03:32 PM
This bug is extremely frustrating, and as a previous poster pointed out - very destructive.
For apps which rely heavily on enums (i.e. leveraging event-driven state machines), this bug makes the Search feature a HAZARD/LIABILITY rather than TOOL.
I would like to subscribe to this bug for updates, but I can't find the NI bug tracking portal for accessing the CAR number you provided. Please elaborate on how to do this.
06-12-2012 11:59 AM
Hey what_tha_G,
Bug fixes are listed in articles, such as the one below, for every new release of LabVIEW. You can check these tables to find out if the bug has been fixed in that version. Otherwise, you'll need to contact NI Support directly for an update.
LabVIEW 2011 Bug Fixes
http://www.ni.com/white-paper/13257/en
Hope this helps!
Ryan S.
08-08-2012 12:04 PM
Any news on a patch for this bug? Is this going to be solved in 2012 version?
08-08-2012 12:12 PM
08-13-2012 10:02 AM
Hey All,
I wanted to clarify my previous statement. Each new release of LabVIEW is accompanied by a document that lists bugs that were fixed from the previous version. However, the list of bugs provided in the document is a subset of the total issues fixed. For specific CARs not found in the release document, you'll need to contact NI Support directly or post on the forums.
I am happy to report that this specific bug, CAR 354380, has been fixed in LabVIEW 2012.
Hope this helps!
Ryan S.
08-13-2012 10:18 AM
Ryan,
Thanks for the good news. This bug continues to significantly affect my development. Could you follow up with the PSE to see if the fix is applicable to LV 2011 SP1? That is, can we get an updated DLL or patch? At my office, we won't be upgrading to LV 2012 until SP1 releases in February. Seems like NI could roll a fix for LV 2011 since you've identified the solution to prevent others from discovering this the hard way.