Allow Multiple Case Selectors along with shared, not separated selector labels

[MimiKLM]

Yes, it might sound like duplicate, but please read it. Of course I'm aware of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780 and http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Multiple-case-selectors/idi-p/1084878

I'm thinking of arming the case structure in multiple, named selectors along with shared, not separated like  http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780, Selector labels. 

The structure could looks like below. Please mind that, due to my graphic skills, I didn't draw the Selector label. Instead, I present example of instances below the picture.

The Selector label would be consist of elements for example like that:

Selector label 1  ---  Test 1 pass?: True, Test 2 pass?: False ---> Test 3 pass? doesn't matter in this case

Selector label 2  ---  Test 1 pass?: False ---> Test 2 pass? Test 3 pass? don't matter in this case

Selector label 3  ---  Test 2 pass?: False ---> Test 1 pass? Test 3 pass? don't matter in this case

Selector label 4  ---  Test 1 pass?: True, Test 2 pass?: False, Test3 pass?: True 

Rest of the variations handled by Default case.

Maximum number of cases 2^n, where n is number of selectors. We can think about limiting the the number of selectors.

Value added by this idea:

-- avoid nested cases - better visibility/readability - lower cost of delivering the code

-- works as a table of truth but not only for decision making but it executes the code in the cases

-- not every case would need to be explicitly defined; actually when we create this structure it can be born only with one case - Default, then by explicit definition of every case we can make our code case by case, letting the Default case implicitly handle all cases not covered by us.

-- can work with the string/rings/enums

[jcarmody]

I typically address this case by building an array of the boolean inputs and switching on the number (with the radix showing & set to boolean in the selector label).  This doesn't accommodate the "doesn't matter in this case" without putting both values.

[AristosQueue (NI)]

If it includes any sort of "or" statement logic, then it falls afoul of the objection I raised in when I thought he intended to allow "or" logic.

If it is just a textual way to do "and" of values, then it is functionally identical to Darin's idea just with a different visualization of the selector.

Darin's solution is superior in that there is a visualization for the order of evaluation of the terms, and a place where a programmer could reorder that evaluation without changing wire position. In yours, I'm guessing that you intend that the ordering of the "?" terminals along the left edge implies the order of evaluation. Yes? Since I assume you still want the cases to all have to be orthogonal (as opposed to complex compound statements that are evaluated in frame order), we would need to know the evaluation order of the terms. Is the Y-axis position of the "?" enough? That seems pretty weak to me.

[X.]

Have you thought about this approach instead? No need to change the Case Structure, which might rapidly end up in a mess of wires (not mentioning AQ's objections)

Note that in its general form, it is described in another of DarinK's threads here.

In practice I suppose that a simple template VI rather than a XNode would work just fine. I haven't bothered to create one yet.

[MimiKLM]

As I can see I'm a victim of lack of digital drawing skills 🙂

The Selector label here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Multi-input-in-case-structure/idi-p/2987215 is what I described in this post, but I couldn't draw.

I'm promising to improve :-).

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.