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!
cancel
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".

Before.png

Now the program behaves as if triggered. 

AfterEdit.png

 

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?

OpMode.Better.png

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


GCentral
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
Member

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 🙂 )
Member

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