LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

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

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:

harmless function.PNG

Delete an element:

remove element from enum.PNG

Callee changes but doesn't warn the coder:

bad day.PNG

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.

CLED (2016)
Example Gatekeeper

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

DNatt, LV R&D

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...

Active Participant

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 8)


*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.

Active Participant

-- 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.



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

CLED (2016)