cluster typedef doesn't update correctly

[pjr1121]

Hello everyone,

I am new to using typedef controls so i'm hoping that I just overlooked something simple.  I am using a cluster typedef control in Labview 8.6 consisting of enumerated controls and a few numeric controls.  I've noticed that when I change the typedef cluster, it does not update properly on the VI in which it is used.  A specific example, which has been driving me crazy:

I decided that I need to change one enumerated control within the cluster so it's name is more descriptive and it has more options.  So i open the typedef control, change the name, and add two items through edit items... Save and Close.

Now, when I open the main VI that I use, I see that the name of the enumerated control has updated, but the new list items are missing.  Since Auto-update is selected, I can't click Apply Changes, since they were technically already updated.  To get around this I have to delete the typedef control and add it back in.

Since the name is updating, I know that it is linked properly.  Did I do something wrong when making the typedef control?  I've attached the control itself, although I doubt this will help.

Thanks.

[mikeporter · Accepted solution]

It'snot updating because you don't have any enumerated types in your cluster - they are all ring controls which by design do not automatically update when the typedef is changed.

Mike...

[pjr1121]

Just out of curiosity, could you explain why ring controls do not update?

[nathand]

Item Lists of Combo Box/Ring Constants Do Not Update from Type Definitions

http://digital.ni.com/public.nsf/allkb/46CC27C828DB4205862570920062C125

[mikeporter]

The point is that a typedef only fixes the datatype of a control and the datatype of a ring control is an integer. The strings that are associated with the control are not part of its datatype - so they don't update when the typedef changes. If you want the list of labels to update, use enumerated types where the labels are part of the datatype.

The good news is that if you go to your existing typedef cluster and replace each ring control with an enum LV will automatically populate the new enumerated control with all the labels that were in the old ring control - any you will notice some other changes that I think you will like. For example, wire an enum to the selector node of a case structure and the cases will be labeled the values in the enum - not 0, 1, 2, etc...

Mike...

[DaveKlapp]

I'd like to push this up to the labview dev folks and ask why could a string outputing version of an enum not be created and functional as a type def. I understand the difference between enums an rings. But I would like to suggest that the powers that be create a data type version for strings similar to the enum which updates all instances of a type def when changes are made to the string content within. 

To draw a parallel. An enum pairs the string label with a number and packages the two as part of the type def. Instead could we not pair the string label with a string and again package the two as a type def? You could choose to have the label and string content match or not as needed but the pair would update universally.

Here is one instance where this would be useful. I have been using the Asynchronous Message Communication Library lately which utilizes the standard Labview queue funcitons. While the standard queue functions can accept various data types the AMC library is limited to string messages only and rewriting the entire AMC lib is time prehibitive. 

So it would be very convienent to have something that looks like a combo box constant as a type def to feed into the AMC libraries instead of individual string constants. It would significantly reduce errors when repeatedly typing the same sting constants repeatedly only to find them the hard way after hours of debug.