07-18-2012 09:51 AM
So, I believe that I finally have a better understanding of this issue and this thread. A key point that I missed earlier, was that the affected users are only running LabVIEW 2010 (or SP1).
The reports from LabVIEW 2011 or later were not strictly issues with "LabVIEW chang[ing] enumeration constant values randomly", but other issues related to enums or source-only.
It turns out that CAR #277004 was responsible for tracking this issue and was fixed with LabVIEW 2011. The fix involved a significant change in how type-defined controls are tracked by the source-only infrastructure.
If anyone is still encountering this issue, I would encourage you to upgrade to a later version.
Thanks for everyone's help with this. Please let me know if there's any related questions that I can address.
Thanks again,
07-26-2012 12:16 PM - edited 07-26-2012 12:19 PM
I am seeing this behavior after building a packed library where it changes the value of my enum typedef. In the VI I have it set to "Y" (U16 value of 1) and then after the build it sets the constant to "X" (U16 value of 0, or it's default value).
I am not separating the compiled code from the VI like the previous posts.
I am using LabVIEW 2011 SP1 f1
Has anyone else seen this behavior?
Thanks.
07-26-2012 01:54 PM
Hi Qbits*,
The issue you are describing appears to be a separate issue that we've documented internally as CAR 335830 "Control defaults can be lost when library is built into a packed project library".
I'm in the process of including it in the LabVIEW 2012 bug fix list, so hopefully it will address your issue as well.
Thanks,
03-17-2014 04:30 AM - edited 03-17-2014 04:35 AM
I'm using LabVIEW 2013SP1 and am running into a similar issue. Importantly, my compiled code is NOT separated from my VIs.
I am trying to remove an Enum typedef (non-strict) from a class library. From the project window, I right-click on the typedef and select "Remove from library."
Every time I've done this, it causes ALL the typdef's BD constants to revert to the default "0" value. This is enormously problematic, obviously. Clearing the compiled object cache as suggested here does NOT resolve the problem. I'm forced to revert to the earlier copy on source code control. But it's vital that I am able to remove the enumerated constant to untangle some undesirable code dependencies.
Anyone have other troubleshooting suggestions?
03-17-2014 05:55 AM
I can't say I have experience with this issue, but there are some options which come to mind for this specific case: