Enum and Case selector in LabVIEW

[plessnick]

Hello,

Is there a way to turn off LabVIEW case selector "intelligence"?

I have a enum control which is a type definition connected to a case structure.  Let's the enum values to be "A", "B", "D","E","F".

I want a specific case for values "B", "D" and "E".  I enter manually the value in the case selector and LabVIEW changes this with "B".."E".  I do not want this, I need to have the three elements listed as "B", "C", "E" .

What is the difference?  My code is part of long-life project where people may modify the typedef over time.  Let's say that someone modify the typedef for "A", "B", "C", D", "E" and "F".  The case structure would then be executed for values "B", "C", "D" and "E"....  which may not be the requirements at that time.

Can the automatic replacement of  "B", "D" and "E" by "B".."E" be turn off in any way?

Thanks,

Patrick

[LV_Pro]

I'm not seeing what you are describing. I created a typedef, A,B,C,D,E connected it to a case statement, manually entered "B","D","E", which it kept. Added a case "F" to the type Def.

See the pix

This is in version 8.5 full dev edition

Message Edited by LV_Pro on 09-30-2008 03:34 PM

[plessnick]

Hello Putnam,

Do not put C when you first create the typdef.  LabVIEW would replace B,D,E by B..E

Update the typedef to A, B,C,D,E,F.  The case selector isn't updated and is still B...E, so the case B..E would execute when a value of C is passed to it.

The problem won't happen if the C value is added at the end of the enum or if a different case is made for each value.  However, this is not what I want on a software engineering point of view (I may have decides to list states of a system in alphabetical order).  It make no sense to replace contiguous values of an enum by the ".." operator as "B".."E" may have no sens in the physical world where "B", "C", "E" has.  We are using enum to make application more readable and easier to maintain.

Regards,

Patrick

[RavensFan]

I see what you are saying.  But I'm not so sure if what you have is that big of a problem.

Any time you would add another item to an enum typedef, and you add another case to a case structure, that is really a major change to the code that should not be taken lightly.  Whoever is doing changes like that should know the program well, know what it was before, what it should be after, and just make one change at a time.

Yes if  you add a "C" between B and D, that automatically becomes a part of the B...E range.  But if you add a C, particularly if you are essentially reordering your enum which could potentially have other major implications in your code besides the update of a type def, you should already be planning to add a C case to the case structure.  Once you do that, you'll see the code breaks because the C is no longer unique in the case structure.  Once it breaks, you can go and find out why and see that you have a B... E range, and because you know you added a C in to the middle of B D E, you know what's going on and can edit the header of that case so that it becomes B, D, E and it will fix the broken run arrow.

You can't really expect LabVIEW to read your mind and know how to handle future changes to the code that you may not even know yet.  And if you were doing much larger ranges such as for integer values, would you rather have the case structure be 1...100, or have it be 1, 2, 3, 4,, and so on, risking the chance of missing one, and being unreadable in the header, just for the slight chance it can't possibly know about that you would add a new case in the middle and thus make the original series disjointed.

[Intaris]

You should cluster your enum elements logically, not alphabetically.

If you have some reason to have B...E as a choice, then that should represent a logical grouping in your enum.  You can always add a "C" at the END of the enum to provide a different grouping.  Enums are not designed to be used for user interfaces, so the lack of alphabetical sorting should not be a big problem.

Shane.

[PhillipBrooks]

An enum can only be a data type of integer. It consists of consecutive values from zero to n-1 (number of elements in enum).

LabVIEW replaces "B","D","E" with "B...E" because  it is using the integer values from your enum to select the case, not the labels.

As you add cases to your long term code, add the new items to the end of the list. Other programmers shouldn't care about the order of the items in the enum; they are selecting based on the label.

If you need to present the items named in the enum on your front panel for an operator, extract the enum strings at run-time and reorder them (presumably alphabetically). See example