Case structure: prevent automatic change from selector value list to value range

[Andi_S]

If the case structure is used with enum or numerical values as selector type LV automatically converts value lists to value ranges. On the one hand this is nice to keep the header small but on the other hand it can lead to very hard to find program flow errors.

But let's have a look to the pictures first:

left: the value list I entered to the selector field;          right: the range that LV creates automatically:
 
 

Here is the complete piece of code showing that there are four values in the enum constant and that each value is handled (no default case required):
 

What happens if you ...
a) .. extend the enum between "case 3" and "case 4"?: The new value(s) will be handled in the case ""case 2" .. "case 4""
Do you always want that the new value is handled in this case?? I don't!
b) .. add a new line to the enum before case 2 or after case 4?: The VI can not be executed anymore because the value is not handled in any case of the case structure.
Now you have to adjust the code => more work but you're sure that the code is doing the right thing.
c) .. have a default case and you add the values to the enum as described on a and b: The code would be executable each time but only on b it will be handled in the default case.

Usually I want to decide how a value is handled, meaning I want to extend or change the case structure by myself and I don't want to be forced by LV to keep care of a special order of values inside of my enum typedefs.

Because of this I suggest to add a new option to LV block diagram configuration: "automatically change case structure list of values to value range: never / ask / always".
The default value for this option should be "ask". In a situation like shown on the first image a dialog like this can appear:
 

If the users selects "yes" the code will change to a list like shown in image 2. If he selects "no" the case structure remains like he has entered the values (image 1).

[X.]

I was pointed to this idea after having compained about the same thing here.Definitely needed. Kudo.

[Matthew_Kelton]

For me at least, this is such an uncommon occurance.  It has been frustrating in the past when I forget where a case is in an enum list and I try to hunt it down.

I think I'd rather see it as a new dialog box, something similar to the Edit Items dialog for Enums and Rings, or even the Event Structure dialog.  The display can remain the same, but you have a dialog window that allows it to be exploded and you can remove or add items there.

If you want your behavior, I woudl say you need to make it switchable.  Just a right-click show compact or non-compact.  This way, the user can switch back and forth instead of it being locked in.  If I inherit your code and like it compact, then I should be able to change it.

I don't even have a problem with a global option for it and the user cannot change individual case structures.  This at least means when you get the code back from me, you won't have to change all your displays back.  I have it set to compact mdoe, you have yours set to non-compact mode and everyone's happy.

[X.]

Totally for a complete rewrite of both the Case Structure and Event Structure case list management (as discussed in other threads). But this is not going to happen tomorrow because it's tough, whereas this behavior might be easy to "fix" in the meantime.

The main problem is, as described by Andi S, that you can mess up your code if you are not careful.

[X.]

I guess the point is that LV should not try to go ahead of the user's wishes.

If one does not care to have "Case 1, Case 2, Case 3" transformed into "Case 1..Case 3", that should not be done automatically, but only as an option (right-click option?). Of course, if one wanted to treat cases "1..10, 100..200, 1000..2000", it would be clearly inconvenient to not be able to type it as I just did, so being able to use this notation when defining cases is useful.

Note BTW that the second example involves integers while the first one involves names (which happen to have numbers in them, but the same shortcut is employed (automatically by LV) when the names are those of successive items of an enumerated value, whether or not these names comprise numbers.

[sbus]

What a novel idea; LV could do it THE WAY WE TYPE IT IN.

If I type A...C then so be it, If I type A,B,C then so be it!!!

And I can always change it!!!

[SteenSchmidt]

Please PLEASE raise the priority of this. I'm just back from a debugging session where this has costed me many many hours of needless failure searching.

I really can't live with LabVIEW automatically changing my case selection values into a range. Both selection types are fine, but please let me choose which one to use myself. Especially with enums it's a bomb waiting to wreck my applications. With a numeric case selection you don't risk suddenly introducing a new value in the middle of a selection like "2,3" for instance, but if it was an enum you could.

A real-life example:

There was a command-enum with values like these:  Disable, Clear, Other 1, Other 2, Enable. A case structure where one case should handle three of these commands existed in the code: "Disable, Clear, Enable". At some point in time someone changed the enum values to alphabetical order (shouldn't pose a problem as the enums are identified in LabVIEW by string value). Unnoticed by the programmer this made LabVIEW automatically change the above case selection to "Clear..Enable". The application still worked as expected. But then someone added a new command 'Connect', which incidently ended up in the middle of that automatically generated range! The programmer now fixed all broken arrows (since LabVIEW throws a broken arrow when any enum values are left unhandled in case structures), and thought all was well. A long time passed where the application failed mysteriously, until someone else hunted down that the Connect command at one place was handled by the same code as Clear, Disable and Enable. 'Connect' is not even visible nor searchable in that location. It's such a downer finding this.

Automatic change into a range is a bigger bug-hole than adding a Default case for enums, since the Default case you add yourself and should know about, while the range can appear by itself. For sure you're rewarded with a 'changed' asterix on the affected VI, but this might easily get overlooked in a project with thousands of VIs. By using an enum instead of a ring you trust you have added the necessary layers of protection to your code so you don't have to manually walk through each and every enum instance when you make a change. It's even a question in some certification exams: "When can you trust LabVIEW to make correct automatic updates when you change an enum?". The correct answer to that is "Never!".

Cheers,

Steen

[robijn]

I'm a big fan of "keep it as I have typed". If I want a list of items, I will type a list. If I want a range, I will type a range. If I forgot to type a range instead of a list of items, it is my mistake.

Currently, I often have to change things back when I've inserted some item in an enum. Very dangerous, because you only find out because somethings has stopped working correctly.

What could be done better in the IDE is that labview tracks better how the user changes a typedef'd enum. If one inserts items, there is no problem (LV will remap the instances based on the enum text). If one renames items, there is also no problem (I think it will keep the numeric values for remapping existing instances). But when combining renaming and inserting actions wirthout re-appying inbetween, it will go wrong. With better tracking of what the user is changing while editing a typedef'd enum, this can be prevented.

[Tom_Hawkins]

Don't have yet another option - please! Just eliminate the undesired behaviour. LabVIEW should definitely not do this for enums. I'm not sure what the best way to handle strings or numerics is but there's a good case (sorry!) for the 'keep it as I typed it' way.

[wiebe@CARYA]

This was on my list to propose myself. Kudo's. This can ruin your application, and you won't have a clue. The customer might find out before you.

[X.]

I guess "the developer who authored this piece of code has left" (and nobody feels that this is sexy enough to revisit).

The beauty of proprietary code where developers decide about the criticality of a bug...

When they condescend to recognize it as a bug, that is!