Class based typedef broken

[xl600]

I have a class containing numerous typedefs which are used throughout my design.  These have not proven to be an issue until just recently (After updating from LV2015 to 2016).

A few days ago, I was suffering from multiple new errors which I've never encountered before in multiple previously checked out pieces of code.  I performed a cach clear and mass compile.  After doing so, ALL VIs of ALL my classes claimed to have been modified (I separate compiled code in all VIs) which surprised me since none of the unmodified VIs should have indicated file level changes.  VIs in non-class based areas behaved normally.

In addition to all VIs showing binary differences, the typedef based constants (Originating in those classes) throughout my design (I class VIs and outside class VIs) have suddenly stopped working.  None report broken and none have been modified (Haven't added or removed values), yet many do not result in the value the constant indicates (They all return the default typedef value now).  When I go to the type def, no errors are indicated.  It's just that the constants aren't producing the selected constant values.

What on Earth could be happening?

BTW: This is all happening on my RT code base if that may have some impact on the issue.

Thanks,

XL600

[xl600]

<Duplicated message>

[GatorChomp]

Hi xl600,

Can you include some screenshots of the behavior you are describing? I'm assuming you're referring to the class's private data cluster when you say typedef, but I'd prefer to have that confirmed than making an assumption. 

What was your upgrade process between LabVIEW 2015 and LabVIEW 2016? What do you mean when you say the typedefs aren't producing the constant values? 

Some more details about the behavior you are seeing would be much appreciated!

[xl600]

No, I have a bunch of typedefs that are used both in and out of the class.

Yesterday, I simply moved the constants that seemed to be giving me trouble on the block diagram.  After saving the VI, they no longer output the wrong values and I haven't been able to find another instance which does the same thing.  Granted, I have barely worked through the hundres or so VIs that might be affected.  If it happens again, I'll grab a screenshot.

Basically what it looked like was a typedef'd constant and a probe showing the wire connected to the constant.  The probe showed "Undefined" (Which is my first value for all my typedef'd enums) even though the constant showed a different value and no errors were declared by LabView.

[xl600]

One thing that may be related.  i was using LabView RT 2016 from Nov 2016.  This is before the 2016Q4 patch addressing CAR#593319.  I do write to TDMS files as described in the CAR so there may have been some weird memory corruption going on.  I just finished installing the patch and will be watching for odd behavior.

[GatorChomp]

Glad to hear the problem isn't happening any more. If you can manage to get the problem to reproduce, please share that so we can dig into the behavior further. 

I don't know that the patch would have resolved that behavior as it was specifically for the RT OS. To my knowledge that should not have had any real impacts on the behavior in the development environment. 

[xl600]

The issue was happening on my RT OS side.  I don't know exactly how the RT OS and the development environment interact for things like probes or front panel interactions.  But it did visibly manifest on my dev side and was obviously acting incorrectly on the RT OS side (Which leads me to believe the dev side was showing the 'truth' that the constants were'nt being output correctly).

[Ben]

---

@xl600 wrote:

...

...  It's just that the constants aren't producing the selected constant values.

What on Earth could be happening?

BTW: This is all happening on my RT code base if that may have some impact on the issue.

Thanks,

XL600

---

If the issue i that the default value that you specifiy either in the control editor OR latter for constants on a diagram are lost.... that is the nature of the beasts (type defs). I warned about that issue in my notes from my Type Def Nugget from ten years ago. (see notes >>> *** ).

If you need specific values in any part of the private data of a class, it should explicitly be set in an "init" type method when the class is instanciated.

Old-time insight:

In a very old version of LV (maybe 6i or 5.1) running on a old PC that was heavily loaded, I was able to watch the type-def propgatin in slow motion as an instance of a type-def was built-up one element at a time after the containing cluster was initialized as emty and each element added one afte the other. While you can not see that happening now, I belive the underlying code is still similar.

Now to speculate on why only in LVOOP data it is happening...

LVOOP classes have a built-in feature that will allow instances of the class data to be written directly to file and read back AND be able to adapt such that a file that was saved with an old version can be read even after the LVOOP private data has been modified (this is rather impressive becuase the read from file is more than a type-cast to the LVOOP class data). Since you observed this after upgrading your code from an older version of LV, I suspect LV has saved the old version of the LVOOP data and replaced it with new versions in the upgrade process.

Trying to help,

Ben