LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
550nm

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
P@Anand
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
crossrulz
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
Mythilt
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.
parthabe
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 2024 🙂 )
550nm
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

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