Diagram constants changed by IDE when editing enumerated types

[550nm]

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?

[P@Anand]

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

[crossrulz]

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

[Mythilt]

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. 

[parthabe]

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

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.

[550nm]

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]

Hi 550nm,

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

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

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.