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: 

Diagram constants changed by IDE when editing enumerated types

Status: New

The LabVIEW IDE may coerce diagram constants when the enumerated typedef changes.  The problem is: the constants may occur in many places, and the coerced value is not necessarily helpful.

In the pictures below, the "Idle" element is removed from the typedef and the IDE coerces the diagram constant to a neighboring value "triggered".


Now the program behaves as if triggered. 



When a diagram constant becomes invalid, wouldn't it be better to flag it as broken, so that the programmer is forced to handle the problem?


Trusted Enthusiast

I personally like this idea since it would save some time for the developer. 


The best solution is the one you find it by yourself
Knight of NI

For clusters, there is the Review Updates.  The same mechanism could be used for enums.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5

Review Updates does sometimes kick-in when you change a typedef'd enum, but it is more when values are moved, deleted and renamed, rather than simply deleted.  Not sure what specifically triggers it. 

Jon D
Certified LabVIEW Developer.
Trusted Enthusiast

To avoid this coercion happening, it is a better programming practice to "Remove Default" and use "Add Case for Every Value" instead! Smiley Happy


Why would someone want to use Enum Typedef, when you do not know exactly what all the states you would want in your program.


If that is the case, I'd suggest using a String-based state machine, wherein your having a Default case would not cause any harm because your code wouldn't coerce in first place.

- Partha ( CLD until Oct 2021 🙂 )

Hi Partha,

Thank you for your comment! (however...)

The problem is that the IDE is changing the source code, creating hard-to-find bugs.  The IDE could be identifying the problem, as it does when a named-cluster-element becomes invalid.

The problem is not solved by having a case for every value.

The idea that one shouldn't use an enum unless it will never be changed is a bit nieve;  adding and removing enumerated values is a natural part of editing the code - whether during development or maintenance. 

The enum typedef encourages correctness by constraining possible values to a specific set of legal values; use of a string enables a kind of value-related bug that is impossible with an enum. 

 - 550nm

Trusted Enthusiast

Hi 550nm,


Thanks for the clarification! Earlier, I got it wrong, totally! Smiley Happy


Even when we do not have Default case (because of the "Add Case for Every Value" being set), I could reproduce this nasty issue - "coercing to the nearest (next) value". Smiley Mad


Although the VI containing the Enum Typedef gets broken, no wire is broken. The reason for the breakage is "A selector value is used by more than one case.  It may be in the middle of a range in one of the cases.".


If we remove the last item, at least the CS label shows in red, which is a visual clue that something has been done to the Enum Typedef.

- Partha ( CLD until Oct 2021 🙂 )