Enum and Ring Data Types - Discussion

[SercoSteveB]

I like this question but can't settle on a good set of multiple chioce answers, so thought we would have the first Discussion question.

Consider the following VI.  We have wired Enum and Ring data types to two Case Structures.  The Case Structure receiving enumerated data accepts "Likes LabVIEW" as a Case Selector Label but the Case Structure receiving ring data does not (as shown by the red text).  Why?

[crossrulz]

Because rings do not contain the text in their data type.  The ring data type is really just a number.

Rings can change elements.  Enums are set in stone (at run time).

[MrStevenUND]

ENUMs are stored as strings and cannot be modified programmically.

Rings assign a number to each string, and at runtime only the numbers are used.  I believe Rings can be modified at runtime using properties.

[2verb]

The two types have a different relationship with strings.

The ENUM has a fixed one to one relationship with strings. For each numeric value, there has to be a unique string value. As has been noted, the strings cannot be changed at runtime.

The Ring control does not have this one to one relationship. Different numeric elements can have the same string as each other.

Because of the one to one relationship with ENUMs, there will be no confusion in selecting the string in the case structure. The string can only refer to one numeric value.

This is not guranteed with the Ring control. As an additional problem, the string can change at run time. While you may not have had duplicate strings at design time, changing to duplicates at run time has the potential to break the case structure.

I am guessing that the LabVIEW developers, in order to prevent these kinds of problem, don't allow you to use the strings of a Ring control as a case selector. This probably also makes the under the hood code easier.

Put simply, the string of a Ring control is not a unique identifier of the numeric value because the ring type allows duplicates and the strings can be changed at run time. Therefore LabVIEW cannot determine which numeric value is intended to select which case and does not try to guess.

[MrStevenUND]

2verb wrote:

I am guessing that the LabVIEW developers, in order to prevent these kinds of problem, don't allow you to use the strings of a Ring control as a case selector. This probably also makes the under the hood code easier.

You can use Rings as an input to a Case selector.  However, it is the numeric value associated with it instead of the string.

[SercoSteveB]

You can modify enums programatically (at run-time), it's just that the VI containing the enum must be in edit mode.

[crossrulz]

SercoSteveB wrote:

                       

You can modify enums programatically (at run-time), it's just that the VI containing the enum must be in edit mode.

                   

If the VI isn't running, it is not in run-time.  You can modify enums using scripting.  But that isn't really run-time.

[SercoSteveB]

Agreed, you can only modify the values of an enum if the VI containing the enum is in edit mode.

The point I don't want people to forget is that it is possible to modify enum values programatically.  Here I am modifying the values of an enum called "StevesEnum" that resides in the VI identified by the vi path control.

The crucial point is that you are modifying the enum from a different VI (and that the enum VI is in edit mode).

If you attempt to run this.......

.... you will get this.

[MrStevenUND]

SercoSteveB wrote:

Agreed, you can only modify the values of an enum if the VI containing the enum is in edit mode.

The point I don't want people to forget is that it is possible to modify enum values programatically.  Here I am modifying the values of an enum called "StevesEnum" that resides in the VI identified by the vi path control.

The crucial point is that you are modifying the enum from a different VI (and that the enum VI is in edit mode).

Does this work with Type Def Enums (strict or otherwise)?  We try to use Strict Type Defs when we use Enums so we only have to change/update one location when a name changes.

[crossrulz]

MrStevenUND wrote:

                       

SercoSteveB wrote:

Agreed, you can only modify the values of an enum if the VI containing the enum is in edit mode.

The point I don't want people to forget is that it is possible to modify enum values programatically.  Here I am modifying the values of an enum called "StevesEnum" that resides in the VI identified by the vi path control.

The crucial point is that you are modifying the enum from a different VI (and that the enum VI is in edit mode).

Does this work with Type Def Enums (strict or otherwise)?  We try to use Strict Type Defs when we use Enums so we only have to change/update one location when a name changes.

                   

Yep.  Using VI Server/scripting, you open the ctl file and do the edits.  But if the control is being used in any running VIs, it cannot be edited.

[SercoSteveB]

Nice thread guys.  Thanks crossrulz, MrStevenUND & 2verb for your input.

[mini09]

That was an clear explanation guys thanks to all...

[mon3am]

hi everyone

i have some questions

can a case structure be configured to display numbers instead of string associated within it ?

a one frame of case structure  can  be configured to hundel to two enum items at the same time?

what a linked tunnel associated with a case structure indicates?

thanks

[crossrulz]

If you wire a number to the case selector, then the number is displayed.  Rings are just numbers.  Enums are a special type of number that uses names to associate the number.  The case structure will always use the names for an enum.  This is desired since this adds to the readability.

A case frame can handle multiple values.  You can use a comma to separate values or use .. to create a range.

Linked tunnels make life easier when adding more frames since it will have those two tunnels wired between them when you create the new case.

[drjdpowell]

You might want to consider a Daily CLAD discussion on the difference between “datatypes” and “controls” (the latter are UI “widgets”).  I see a lot of confusion on the forums where posters don’t realize they they are separate things.  There is no such thing as a “Ring datatype”, for example; a Ring Control is a UI widget that displays an integer datatype.  There is an “Enum” control that displays an enum datatype, but they aren’t the same thing either, even though (confusingly) an Enum control is the UI for editing the enum datatype definition.