Multiple instances of enum typedef were they have different control styles (modern, silver, clasic etc.)

[tshurtz]

Is it possible to have multiple instances of a given enum where the instances of the controls are not all the same style?

For example I have two vis, one where the controls are all one style (such as classic), and another where they are a different style (such as modern). I would like a control in each where they are tied to a single typedef of an enum (such that they have the same items available), but have the style that matches those of the other vi controls. The all knowing AI seems to think this is simple but its suggestions either don't exist or don't work.

[Kyle97330 · Accepted solution]

Yes, assuming it's not set as "Strict":

1. Put down the original type defined enum on a front panel

2. Select it so that it's highlighted

3. Press Control-space to bring up quick drop (if this is your first time, it might take a while)

4. Type in the type of the enum you want to find it in the quick drop list, like "Classic enum", then select it so it's highlighted in the list

5. Press Control-P, which is the "replace" shortcut

Quick drop uses a different replace method than the right-click menu does, and its replace method changes the style but not the type.  You can see here that I have 5 different type defined enum styles that all match and don't generate coercion dots:

Unfortunately, if you do update the enum with new values, all the controls will change to the default control style and you'll have to go manually correct any that didn't use the default style.

If you want to script, the built in "Replace" method does have a style input you can use:

I'm fairly certain you get the same results as the quick drop replacement if you use that.

[tshurtz]

Great! Just what I was looking for. I tried the right click replace with no luck, but this worked. Too bad it isn't "permanent" but it will have to do. Thanks.

[Bob_Schor]

I was interrupted and didn't finish my response until after Kyle posted his, which was clearer than what I was writing (which can be summarized by urging you to not have two Enums that more-or-less "do the same thing", as it can only lead to confusion).

Bob Schor

[tst]

---

@tshurtz wrote:

Too bad it isn't "permanent" but it will have to do. 

---

I would suggest considering using rings for the UI rather than an enum. You can populate the ring dynamically from the typedef when the VI runs, so that it's always synced with the enum (for instance by having an enum control and using the property node or by having a constant and using the Get Numeric Information VI). Of course, ideally you would want to convert it back to the enum as soon as possible.

[tshurtz]

---

@Bob_Schor wrote:

urging you to not have two Enums that more-or-less "do the same thing", as it can only lead to confusion).

---

Exactly what I am doing. I don't want two doing more or less the same thing. I want two instances that forced to always match options (hence the typedef) but have a matching UI appearance to the rest of their surroundings. In this case one instance is used in vi which generates a file that another vi processes and this enum is an option that can be set in the programming vi but is read, displayed and processed in a case structure in the processing vi, thus benefitting from all of the reasons for using an enum. 

I just want to respect the look/feel of the existing UIs that don't match eachother.

[raphschru]

---

@Kyle97330 wrote:

Unfortunately, if you do update the enum with new values, all the controls will change to the default control style

---

Just thinking, ideally if LabVIEW did a "proper" Type Definition update, only the data type related properties should be propagated to the instances, such as the numeric representation and the enum item names. Any other property should only be propagated for Strict Type Definitions.

Unfortunately, currently Type Definitions propagate the data type related properties + the control style.