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

[AristosQueue (NI)]

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

It isn't condescending to classify something correctly. This isn't a bug. It works exactly as designed and documented. Could it work better? Yes. And that's why this is correctly classified as a feature request. It is a feature that may lead to bugs in your code, and for that reason would be a good thing for us to change, but it isn't a bug in our code.

The developers of this code are still on the team. Modifying this particular behavior has not been a priority compared to the myriad other requests that we get.

[X.]

Your answer reminds me of that car dealer who was explaining that the door window of my father's car was working fine. You just needed to remember not to lower it down too much, because then the mechanism (manual at the time) would unlatch and trap the window inside the door. Basically he was not using it as he should have (from the dealer's point of view).

I guess this is a family trait...

Please say hi to the developers for me and please try to catch up with the 10+ years backlog.

And also whenever you have time, fix the Help to highlight this intended feature, because, unless I am mistaken, it is undocumented.

And BTW, the Case Structure Help is wrong about this:

"LabVIEW warns you that you will lose hidden cases, frames, or subdiagrams and asks if you want to cancel the operation."

Unfortunately, it does not anymore... I guess you'll remember why.

[AristosQueue (NI)]

Ah... now that documentation *is* a bug. It should have been corrected when we changed the behavior in LV 2013... in response to this high-kudos request from the Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Eliminate-quot-Are-You-Sure-quot-Dialog-When-Removing-...

I'll CAR that we need to update the documentation. Thanks for finding that.

[raphschru]

13 years later, there is still no satisfying solution to this problem!

Here are some workarounds I could use:

1. Use a string instead of an enum -> error-prone:

2. Separate items with fake ones -> really clunky:

3. Use nested case structures and search in arrays -> not scalable:

All these workaround are quite silly, so please, at least for enumerations, case structures should not turn automatically value lists to value ranges!

PS: I know I could use classes with dynamic dispatch, but I would rather avoid it in my real time applications...

[wiebe@CARYA]

Not sure what happened to my '14 kudo.

Perhaps what's missing is concrete ideas to solve this problem?

How about this:

Consistent with the string option Case Insensitive Match. 

Spoiler

OT... Sadly a string range is not consistent with the ranges of other data types. A string range uses [ min, max ) for strings, not [ min, max ] like integer and enum ranges.

The non-inclusive max of the string range makes it very hard to use.

[wiebe@CARYA]

Or would we like to be able to specify this option for each individual case?

Or even per individual range?

We could consider hard and soft separators: "a", "b", "c" -> "a".."c" but "a"; "b"; "c" is untouched.