Case Structure Selector comparison to dynamically changeable inputs

[vladgu]

I want to suggest Case Structure Selector comparison to dynamically changeable values.

Now Case Structure Selector compared to constant Boolean/eNum/Numeric/String values.

I suggest to compare the Selector input to External Inputs, for Example:

If String control wired to selector equal to C control then do the C tab content.

I have experienced similar problems many times when I need to compare the selector to a dynamically changeable variable.

Of course, there are other solutions but I think my solution may be useful.

[AristosQueue (NI)]

I always like it when someone hands me a new structure node to brainstorm about. They're nearly the most interesting part of LabVIEW, to me. I'm supposed to be working on fixing bugs for the next release, but this caught my attention. Sorry, bugs, you'll have to wait. 🙂

At first glance, I really liked this suggestion. It's a somewhat elegant syntax for something that is fairly clunky in today's code -- nested case structures are readable, serviceable, but not clean.

But as I played with it, I saw a problem... what case frame do you execute when A and B have the same value? The obvious answer is "the first frame of the case structure that matches". And that's a fine technical answer -- well defined, easy to explain, easy to implement. BUT... we've currently got a case structure where order of the frames does not matter. That's a really nice invariant that I'm not sure I want to play with. I helped create the Type Specialization structure recently... that node does care about the order of its frames. It makes the user explicitly aware of frame order... but it is still annoying to have to be sure to add a new frame in the right place in the sequence, and reviewing the order is tricky.

So maybe lets modify your idea to make the order of comparisons more obvious. As a side-effect, we can clarify which inputs we're talking about without relying upon terminal names (because those terminals might be the outputs of nodes!). Something like this:

The selection ring doesn't have quote marks, and it shows the index number of the terminal that will be handled by that frame. The custom terminal appearance makes it clear that these are the inputs being selected among. Those frames can be in any order, so we're back to a case structure that doesn't care about frame ordering. And we have made it obvious to the reader of the code the order in which inputs would be checked -- compare against zeroth, then first, then second, etc.

Obviously, this case structure must have a "Default" case for when the String doesn't match any of the options.

The list and range syntaxes for "[Index 0,2]" or "[Index 1..3]" both seem like they'd work.

So, now it is more obvious (in my opinion), what happens when multiple inputs have the same value... the node has well-defined behavior that doesn't rely as much upon checking documentation.

But I still see one problem, and that is this... when the value does equal multiple of the options, it seems likely to me that many developers would need special code to handle that case. Does adding support for this syntax come with a cost such that the advantages of the syntax are lost because you just have to put more code elsewhere? I'm not sure. I leave that as a point of discussion.

If we do need to handle that here, maybe we add another special frame, similar to "Default". Something like: "[Collision 0,2]", or "[Collision 3..5]". Using these might be a performance hit -- they imply a lot of behind-the-scenes string comparison on every call to the case structure, because the structure would have to test all of those before we even start comparing the String. That could be folded out in a local loop, but it would be harder if those values came from a computation. This may not be a good idea. I put it out there for consideration.

So, that's my analysis after an hour or so of kicking the tires on it.

What I don't know is whether it is worth the time to build this node. How common is this sort of thing? Generally, if I have something like this, I write the nested case structures once to compute some sort of enum value, and then use the enum value everywhere downstream in my code. Computing the enum gives me a place to test for equality with multiple strings, if that's relevant to my code... I can either return an error or make the collisions part of the enum value (for example, "A", "B", "C", "AB", "AC", "BC", "ABC"). So I don't have to write that comparison code very often, and I often do need to be able to check for the collision cases.

Interesting syntax. With infinite time and resources, I'd like to see it. But my suspicion is that it solves too niche a problem to ever be implemented. But I don't know that, so we'll leave the idea open and see what kind of kudos it develops if other users think they'd use it.

[Moran78]

It is a very good idea!

i also needed to update case structure selector according to external file and it would be nice to this ability built in the labview environment 

[wiebe@CARYA]

If the case names are going to be index 1, index 2, etc, You might as well use a search 1D array.

If you really want this, you could make an XNode that:

1) gets the labels of the wired inputs

2) creates an enum so the case names will match

3) returns the value depending on the compare result

At run time it won't do much:

1) put all compare values in an array,

2) and run a Search 1D Array

3) cast the result to the enum  

Wire the enum to a case, and you'll get the labels in the case.