LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

enum based case structure

Solved!
Go to solution

I've inherited code that extensively uses (typedef) enums as the case selector. There are usually only 2 or three distinct cases, so all the enum items are functionally grouped together. The enums are listed in the case structure individually (if they are not contiguous) or they are lumped together in ranges in the selector label. The "range of values" is the thing that is giving me headaches.

 

In order to modify the code, I need to add items to the enum typedef. Depending where I add the item, different actions may occur. If I add an item between two consecutive items, it creates a range (no broken arrow) and uses that case. If it is placed within an existing range, it also uses that case for the range (no broken arrow). I can add it to the "End" of the list without any problem until the customer wants the choices sorted differently. Even after getting the program to work, re-sorting the enum causes the case structures to recalculate the ranges. This can either break the code or it can use an unintended "range" case. That is a debug nightmare.

 

I searched on the forum, and the only solution that I found is to have a case for each and every enum item (this by definition would imply NO RANGES). This seems like overkill especially if I have 20 or more items in the enum and there are really only two choices in the case structure. For any small change in the code, I would have to modify each individual case (probably easier to create a subVI and modify that). There's got to be a simple workaround. If I could explicitly select enum items rather than have LabVIEW automatically generate a range, my problem would be solved. Is there a Property to stop the creation of those darn ranges?? Any help would be greatly appreciated.

0 Kudos
Message 1 of 8
(6,724 Views)
Hi,
Read the help for the case structure to learn about creating cases for more than one enum entry!
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 8
(6,715 Views)

I know how to create multiple entries for a case structure. That is not the issue here. The issue is when I change the enum typedef (adding or re-sorting items), the case structure selection gets corrupted because of the way the case structure handles "ranges"

0 Kudos
Message 3 of 8
(6,696 Views)

I am assuming my issues stems from the fact that when items get added or re-sorted to an enum, the item "name" gets assigned a new "Value" and this value is what the structure is using to decide the case. If this is true, I guess there is no easy solution. Is there a way to display the names in a particular order without reassigning a new value to the name?

0 Kudos
Message 4 of 8
(6,688 Views)

If you are using ranges for an enum, that sounds like you are using it wrong.  But, yes, if you resort the items in an enum, the ranges will also get all messed up.  It is considered bad practice to reorganize enum items.  If you need more items in the enum, you should just add to the end.


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
Message 5 of 8
(6,678 Views)
Solution
Accepted by topic author jamiva

Use a text ring instead of an enum.  The enum changes the values to stay sequential.  A text ring will allow non-sequential values.  When resorting a non-sequential text ring, the value assigned to a specific item will move with it.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 6 of 8
(6,677 Views)

Thanks crossrulz. This is not my code but I have reorganized enums in the past and it caused me many problems back then. Didn't realized it was bad practice. Lesson learned.

 

I think I will use aputman's advice and change the code to use text rings instead. It will be a little work now, but will worth it in the end.

0 Kudos
Message 7 of 8
(6,670 Views)

It is generally better to use enums over strings because they are more stictly typed, causing for less issues with things like captialization and typos.  But there are times when I have used strings.

0 Kudos
Message 8 of 8
(6,631 Views)