Rif.: Unable to dynamically change enum file on LabVIEW

[paul_a_cardinale]

---

@skykong wrote:

Actually, I encountered this issue about 10 years ago during my early experience with LabVIEW coding. While there are always workarounds, I'm still curious to see if a proper resolution exists now. but it still seems like a dead end. The reason I prefer using an Enum over a Ring or Combo Box is that a Ring only passes numeric values to the case structure, and a Combo Box requires manually renaming the case labels before use. In contrast, an Enum automatically updates the case structure names based on its items. You can even update the cases and extract state names when needed. Just sharing. Cheers!

 

 

 

 

---

If you think about what you're asking for, you'll realize that it is impossible.

Suppose you have an enum with 3 strings: "One", "Two", and "Three".  And you have a case structure's selector wired to such an enum; and it has exactly 3 cases, and no default.  Then, at run time, you change the enum by adding a 4th value: "Four".  What happens when you send "Four" to the case structure?  There is no sensible solution.

[skykong]

Yes, definitely. It's standard practice to user make all configurations and changes while the software is running. I understand it's possible to configure settings during shutdown, but users typically avoid that since they would need to restart the software to see the changes take effect.

[skykong]

How do you know if my enum case has come with no default? because is selected the “Two” in case image does not mean it does not have default at “One” case selection, it just not revealing it in the image. So if “Four” is inserted it will be handle by defaulted case instead. There is no solution instead of no sensible solution.

[jcarmody]

It doesn't matter if it has a Default case.  It certainly doesn't have a "Four" case so the advantages of an enum never accrue to you.

[billko]

What prompted this discussion anyway?  Is it an exercise in academia, or are you actually trying to solve a problem?

[tst]

First, my personal recommendation is not to have a default case when you feed an enum to a case structure. That way, if you modify the enum, your code can break where you didn't handle the change and you can see exactly where you go to fix it. This isn't universally true, but it's a good rule of thumb.

Like the others, I don't understand your goal, but if you want to have an enum case structure and to be able to map it to a UI element and dynamically add elements to that UI element and have those elements be handled by the default case, I would suggest adding an extra element to the enum, have your UI element be a ring and then in code have a mapping between the ring elements and the enum elements. For each element that you add, set its enum value to the extra element. Then, you use the ring value to find the relevant enum value and feed that to the case structure. Of course, the enum itself won't have the extra data, but you don't have a dedicated case for that data anyway and you can get it from the ring.

There are any number of ways to do this in practice. You could have a couple of arrays. You could use a map or variant attributes. If your numeric values would match, you could use Coerce To Type or Variant To Data to convert the ring value to the enum, but since you want to add values dynamically, this can't work, since the enum itself won't have the extra values.

I don't see that utility of this, but maybe you can explain your use case with a concrete example.