LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Allow Multiple Case Selectors

Status: New

First of all, this is not a duplicate of this, by Case Selector I mean Case Selector and not the label.  It may well be a duplicate of something else...

 

I doubt that I am the only one who uses multiple conditions.  This usually leads to nested Case structures, building boolean arrays, or obfuscated mapping functions between the conditions and some enum.  Other times, the case structure is half-of-a-screen wide just to accommodate the values associated with the different cases.  I would suggest that NI add multiple Case Selectors to the Case structure.  Additional selectors could be pulled down like a shift register, or added via a right-click menu.  Either way, I don't think they should be allowed to cross, so the top-down selectors map to left-right selector labels.  There could be a reasonable limit to the number.

 

19 Comments
Active Participant

Summing up all thoughts, I think is a good idea too. The format should be discussed to achieve better results for all. Kudos!

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Active Participant

Maybe the case selector could trigger something like an express VI if more than one item is wired. Case statement name could be a descriptive name or the anded inputs names. It could also test for mutually exclusive cases at edit time.

 

11-18-2010 9-01-08 AM.jpg

Active Participant

I'm on the same page as Stephen here. Multiple selectors seemed at first like a good idea to me, but I realized I quickly would have a hard time to mentally convince myself that every possible case had been correctly implemented and thoroughly tested. Code stability greatly increases with encapsulation and modularisation. And this suggestion moves in the other direction - it promotes sloppyness. It's obfuscation.

 

When I'm faced with selections based on multiple variables, I often create a typedeffed enum containing the possible outcomes (meaningfully named), and then precede the case structure with the code that calculates the enum value to wire to the case selector. If that calculation is complicated it goes into a subVI, thus encapsulating the selection algorithm for easy documentation, maintenance and replacement. The case structure will also be easy to browse due to the meaningfull enum values (compared to some multivariable logical expression you'll have to evaluate mentally when looking through the selection list).

 

Just my 2 cents.

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
Trusted Enthusiast

> I'm on the same page as Stephen here.

AQ's analogy (aside from being about C) brings 'OR' into the picture which I specifically do not advocate.  So if you have a single selector list of "A&B&C" it is very easy (IMO) to see all of the cases which require testing.  Your preferred method of 2^N-1 nested cases requires flipping though the cases and then each of the nested structures.  Nothing here precludes that by the way.

 

> And this suggestion moves in the other direction - it promotes sloppyness. It's obfuscation.

 

If using 2^N-1 nested case structures and hiding algorithm details in subVIs is your style then that is your perogative.  I will argue that different styles implies neither sloppiness or obfuscation.  This is a simple remapping that IMO is quite effective in the proper situations, which is less than often but more than seldom.  You suspect the possibility of sloppiness and obfuscation, I can show you actual examples involving nested case structures.  These are byproducts of LV users not LV capabilities.  Usable code is abusable code, very few exceptions.

 

> precede the case structure with the code that calculates the enum value to wire to the case selector

 

As you are well aware, there is powerful functionality in the case selector that is either tossed aside or not fully utilized in this preceding code.  Default, ranges, multiple selections are some examples.  Why have a case structure to select an enum to feed to a case structure unless you have to?

 

Some of us are paid when VIs are not running and can justify time spent creating enums and extraneous subVIs.  Others of us are paid by running VIs and justify our LV investment by improving our startup to execution times in the lab.  Syntactic sugar such as this is what I find tips the scale when upgrade decisions roll around.

 

> compared to some multivariable logical expression you'll have to evaluate mentally when looking through the selection list

 

The multivariable logical expression you refer to is A & B & ..., about as simple as it gets.

 

I have an XNode which gets me surprisingly close to implementing this idea.  Having tried it, it is actually quite interesting and leads to more interesting tweaks for the case structure, not a desire to stick to the status quo.

 

My 1 cent.

Proven Zealot

Darin.K: You mentioned an XNode that you have that simulates this behavior. Any chance you could post the XNode somewhere for the rest of us to play with?

Active Participant

I'm kudoing Darin's idea, including the restriction to AND only, especially if he is envishioning a single selector (as he seems to show in his second image), as it would allow one to pull-down a single list of all possible cases.  The list might look something like this:

 

True | Item1

True | Item2

True | Item3

False | Default

False | Item3

 

That would be a lot easiler to read than looking through nested case structures.

Member

I think this would be a powerful feature for error handling also - you could uncluster the error code and wire it and the error cluster to two different case nodes. Then you could have a case for each specific error code you have identified. Obviously that might need refinement but I think it would be neat.

 

Continuing on from this I think a good option would be to give any nodes where an error cluster is wired in an 'override feature'. For example say there is a case structure where two selectors are used - one T/F and the other wired to an error cluster. If the override feature was active then this would result in three cases in the structure - True, False and Error. If an error exists the error selector would over-ride the True/False option and trigger the error case - otherwise true or false would work as normal. If the override is not active the four AND cases (T/Error; F/Error; T/No Error and F/No Error) would exist just as discussed previously

 

A lot of my nested case structures are where I nest my main case into an error handling case to avoid execution when in an error state. If these could be integrated it would make code a lot more readable in my opinion.

 

Active Participant

I think the error handling can be a new idea DeltaJ. But I think the user can connect the error cluster, like he does today, and click on the case structure border, with the right button, to add a case (error number) to have a specific code. All other would be managed (similar to default) by the two standard cases: "No Error" (green) and "Error" (red) to all errors without a specific case.

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Trusted Enthusiast
Trusted Enthusiast

@ErnieH & Aristos: I think this is similar to this idea in response to which Darin K. developed the XNode he is mentioning later (check that thread for the link to it).

 

In response to Darin's idea, I would suggest instead to implement the More General Boolean Operator I discuss in the thread I mention above (which I suggested in order to address pretty much the issue raised by Darin in his presentation). This way, you just take the output of this comparator (which I suggest would be an enum) and connect it to the standard case selector of the case structure...