Deleting an enum element from a type def should cause a broken arrow on Callers that used that element.

[InfiniteNothing]

Currently, if you delete an enum option from a type def, LV just guesses what you want in the calling VIs. This can lead to unexpected results. Example:

Calling VI:

Delete an element:

Callee changes but doesn't warn the coder:

I'd prefer that if it didn't find a string match for each enum reference, that the VI gives you a broken arrow and asks you to replace the offending element.

[Darren]

I have no idea how this could be implemented...but your screenshots successfully garnered my kudos.

[JasonD_at_UML]

I think this might be addressed by making sure you remove the "default" case from your Case Structure.

If I'm understanding you correctly, I do this all the time.

If your case structure has a frame with an enum type that is also the "default", you won't see anything broken when you try to Run. If you have NO default, then it should get unhappy when you feed it an enum this isn't a perfect fit.

The error will be "Case Structure: Selector values are not unique"

-- granted, it won't "break the wire" as you'd like, but it will break the VI, so at least you can go find the error project-wide.

Hope that helps...

[dthor]

While making sure your case structures do not have default case does help, I don't feel that it sufficiently solves the problem.

Imagine a decently large state machine architecture, say 8 frames. You find out that you no longer need frame 4, so you decide to remove it from the typedef enum that defines the states. You don't have a default set on the case structure, so the VI breaks. Good. However, now all the previous frames have shifted names and the enum constants used to determine which frame to go to next have also change shifted. This causes the programmer to have to go back through each case and essentially recreate the whole state machine.

My workaround is to just change the unneeded enum value to something like "do not use" and leave it in there.

Frame labels before and after changing the typedef enum:

Frame 1   -->   Frame 1

Frame 2   -->   Frame 2

Frame 3   -->   Frame 3

Frame 4   -->   Frame 5 (code from Frame 4)

Frame 5   -->   Frame 6 (code from 5)

Frame 6   -->   Frame 7 (code from 6)

Frame 7   -->   Frame 8 (code from 7)

Frame 8   -->   Frame 8 (code from 😎

*Disclaimer: I do not currently have access to LV to verify that this is indeed how it works, I'm just going off of memory where I've made this mistake before.

[InfiniteNothing]

---

-- granted, it won't "break the wire" as you'd like, but it will break the VI, so at least you can go find the error project-wide.

---

Right. It helps but only at the case structure. If you have the enum in another VI, you're going to have to go through each instance of that typedef in your project and see if you used that particular option each time. That's really time consuming and error prone. Also, if you don't use the enum as part of a case structure and instead you just display it to the user, the user might be misinformed.

Another strange situation is where you replace an enum option. In my example, if you replaced "play" with "eat", LV assumes that you were just renaming "play" and now your "eat" case has the code from play in it. I don't think that's a safe assumption. I at least want the option for LV to warn me about that.

Also, there are legitimate reasons for wanting a default case like if you don't want your case to handle every value, it keeps the developer from having to click through a every enum option to make sure the cases that should be inert are infact harmless.

@dthor

I believe that is the case for strict type defs but not for regular type defs. Go figure.