Enum in a Typedef Reverts to Default (LabVIEW 2009)

[Jarrod_S.]

This very much appears to be new to LV2009.

[JackDunaway]

---

Jarrod S. wrote:

Regarding manually bundling in the enum into the cluster, this is something I've been doing religiously for years. Someone told me a long time ago to always do this, because changes to the cluster could affect the constant values of their child controls. I was never sure what exact situations could cause that, but it was just a matter of precaution. So it might be good practice regardless.

---

I do the same thing, but only under one condition - if the parent cluster is a typedef itself. If it's only a vanilla cluster constant on the BD, the child constants inside are safe from changes to the clustered datatype. But if the parent cluster is a typedef, and you modify the typedef, the child constants on BD's are waxed to the null/default value (sometimes). The solution, is of course, to drop a null typedef'd cluster, then bundle by name in your BD constants.

Unfortunately, the situation I described where this "buggy" typedef'd enum is inside a cluster does not fall into the above category, because the parent cluster is not a typedef. So, the fact that the typedef'd enum is getting waxed inside of the cluster now in 2009 is different from our "classical" example of bundling into a typedef'd cluster.

Thanks for bringing this up... it's good to establish that the problems are similar, but probably not related.

Message Edited by JackDunaway (mechelecengr) on 09-16-2009 04:21 PM

[Ben]

Lots of stuff here lets see if I can summarize.

1) Default values in clusters have never been anything we can count on. I mentoned this tidbit and a work-around in my Nugget on Type Definition where I wrote;

"

*** Type def’s define the data type and not the default values. You cannot use type def’s to establish default values. If you modify a type def that is used as constant on a diagram, all instances of that type def will be replaced with new instances. Default values that were saved in the block diagram will be lost when the constant is replaced with the new definition. This is by design. The method I suggest for establishing a default value is to use a sub-VI to explicitly define the value. In the case of clusters use a bundle by name node to set the fields as required. In the attached 7.1 example you will find

 

Type_defd_Constants

Where I have illustrate the use of sub-VI’s to establish default values. In the example, there are two sets of default values of the type definition “Chan Info” (Channel Information) denoted by the green and grayed-out icons.

Documented_Constants

The sub-VI documentation also helps future developers of the application pick-out the proper default settings. 

"

Emphesis added.

2) In pre-LV 2009 there was a bug in the bundle by names getting confused and LV would wire to the next cluster element that was the same data type. If deleting an element we should should change the type deft to a non-comparible type (to break all orefs to that filed) then edit the VI manually to delete all refs to that field and THEN procede. The suggestion from NI was to edit the type def with all callers closed then open the app and re-save.

3) The bug above seems to be related to enums.

What have I missed?

Ben

[JackDunaway]

I just had this bug happen to another typedef'd enum. I can confirm that it is not isolated to the original typedef. In this new case, just like the original, some VI's are affected, and some are not.

[Albert.Geven]

Sorry to say but this is a showstopper.

We will not upgrade to 2009 as enums are not treated better.

We even ask (maybe demand) a switch that stops clusters from being updated  automatically.

Removing an item should always create a broken vi for those clusters that are still using this item.

An automatic update that fails is much worse than not updating in a serious application.

[Jarrod_S.]

A patch (f2) for LabVIEW 2009 is available from this link that fixes the issue noted on this forum along with a few others. It is strongly recommended that all LabVIEW 2009 users install this patch.

[RavensFan]

Jarrod,

Is it necessary to install the f1 patch before f2?  Does the f2 patch include f1?

-Bill

[Jarrod_S.]

I believe patch f2 is stand-alone. You don't need to install f1. The only fix in f1 was for Windows Mandatory Profile settings causing an error during installation. This fix is also included in f2.

[Elijah_K]

The third patch, f3, which includes f1 and f2, was just released, and can be downloaded from here: http://digital.ni.com/public.nsf/allkb/6CE99D0518D392E98625768E00543744?OpenDocument

Click on the link to learn more about the patch and the issues it addresses.

[midam]

Hello,

I think I just experienced this issue with LabVIEW2016 64bit. Is there anybody who has the same experience?

Thanks.

Steve