How does LabView re-assign case structure contents when an enum changes?

[DavidJSzwer]

Suppose you have a case structure with an enum selector. The enum's items are simply "0", "1", "2", and "3". Every item has its own case, no default.

Now suppose you change the type of the enum, changing the item strings. Depending on the new items, the LabView may be able to automatically update the case structure in a reasonable fashion. What algorithm does it use to do this?

My experiments suggest:

• If all the item names are changed, but the number stay the same, the case selector labels automatically change to the new names, in the same order.
• If item names are identical, but the order is changed, the case selector labels stay the same in the same order.
• If some of the item names are changed and others aren't, but those that stay the same are kept in the same relative positions, then the case selector labels automatically change to match the names that changed. This works even if "Red Herring" items are added at the start of the list! Well, sometimes it works. Sometimes, if I make seemingly inconsequential changes (e.g. connecting the enum wire back out of the case structure in the attached VIM), LabView suddenly decides that it should break!
• But if some of the item names are changed and others aren't, and those that are kept also change position, LabView gets confused, and the case structure ends up with repeated selectors.

This is reasonable, and I don't think LabView can do any better than this, but I think there may be some subtleties in the way it makes the decisions. Are these documented anywhere? This wouldn't matter much in normal development, because the code can always be checked by hand or unit tests. But the same process happens if the case structure is inside a Malleable VI - and then the programmer doesn't get any opportunity to check that LabView has got things right.

The example uses a Malleable VI. The case structure inside it starts out with cases "0", "1", "2", "3", and Default. It is inside a for loop that repeats four times, the input enum being incremented each time to step through all its values (assume the input is the first item numerically). The contents of each case are just a string constant showing the original selector value, and a conversion from enum to string (giving the item name). At each iteration, the item string is concatenated behind the constant; these strings are then built into an array which is the VIM output.

"List Items for All Enums.vi" shows the results for some enum TypeDefs that match the cases above; the enum items are listed above each array, and one of them is highlighted to show the input item (that is iterated to step through the values). The final instance of the VIM is broken, because LabView can't make sense of it.

[billko]

That's a tough question!  Instead of answering it, though, here are some things I do to reduce the chances of "unexpected behavior".  Always either move and apply, or change and apply.  Never do the two of them together without applying.  When adding an item, always add to the bottom and apply.  You can then move it where you want and apply.  When deleting an item, always move it to the bottom and apply before deleting it.

This mostly avoids having cases assigned to the wrong item.  What it doesn't fix is if the enum is used somewhere your current project cannot "see" - e.g., an unopened project - the typedef will get updated all at once, and who knows what might happen.

[paul_cardinale]

---

@billko wrote:

That's a tough question!  Instead of answering it, though, here are some things I do to reduce the chances of "unexpected behavior".  Always either move and apply, or change and apply.  Never do the two of them together without applying.  When adding an item, always add to the bottom and apply.  You can then move it where you want and apply.  When deleting an item, always move it to the bottom and apply before deleting it.

This mostly avoids having cases assigned to the wrong item.  What it doesn't fix is if the enum is used somewhere your current project cannot "see" - e.g., an unopened project - the typedef will get updated all at once, and who knows what might happen.

---

I generally do the same except

1. When adding, I just add wherever I want; I don't add to the bottom, apply, then move.
2. When removing, I just remove; I don't move it to the bottom first.

So far this has worked well for me.

[billko]

---

@paul_cardinale wrote:

---

@billko wrote:

That's a tough question!  Instead of answering it, though, here are some things I do to reduce the chances of "unexpected behavior".  Always either move and apply, or change and apply.  Never do the two of them together without applying.  When adding an item, always add to the bottom and apply.  You can then move it where you want and apply.  When deleting an item, always move it to the bottom and apply before deleting it.

This mostly avoids having cases assigned to the wrong item.  What it doesn't fix is if the enum is used somewhere your current project cannot "see" - e.g., an unopened project - the typedef will get updated all at once, and who knows what might happen.

---

I generally do the same except

1. When adding, I just add wherever I want; I don't add to the bottom, apply, then move.
2. When removing, I just remove; I don't move it to the bottom first.

So far this has worked well for me.

---

I've done the move thing because it ensures that the cases don't get out of sync with the items because, like the OP, I have been burned by that in the past.  It seems that LabVIEW does better with enums and case structures if you only ask it to do one thing at a time, and removing from the middle asks LabVIEW to move cases around and delete/add something at the same time.