Cluster to Case Selection

[lvABC]

Currently, we have to use Unbundle By Name from Cluster and select an element for Case Section

It would be great if we could just wire the Cluster Directly and have a Right-Click Option at Case selector to select an element (one element only).

P.S. If it is a reasonable suggestion and gets enough Kudos to get R & D team’s attention for feasibility of this idea, then we ask for more logical operators support that would be useful. Also multiple elements and/or more statement node i.e. (type == Array and # elements <= 2)!!!

Only sometime I miss “if statement” support in LabVIEW. 

Message Edited by Support on 07-16-2009 11:56 AM

[lvABC]

Sorry, Custer it's Cluster.

[JackDunaway]

This one is a slippery slope away from block diagram-based programming into the realm of text-based programming. All of the logic is removed from the BD and placed into text format on top of the case structure.

Although potentially powerful, it could very easily be abused and become a nightmare.

Consider this: a cluster with two numeric elements, a and b. Make a case statement that handles a==1 for the first case and b==2 for the second case. Well, both cases could be true when the case selector is evaluated! Do they both execute? Which executes first? Do we add shift registers to a case structure? Do we have the equivalent of a "break;" to get out of the "switch" to short circuit the rest of the cases?

Like I said, nightmarish.

[lvABC]

Point well taken, but it was thought out.

That is why it was mentioned, “select an element (one element only)”.

So it would not be nightmarish 😉

 

However, in my personal suggestion did mention having allow “Also multiple elements and/or more statement node i.e. (type == Array and # elements <= 2)!!!”. This can be nightmarish if programmer is not careful with it. That does not mean it should be limited.

 

Just an !dea..!

Thanks,

[mfitzsimons]

Just had this idea today.  I like the idea!  Tired of all the unbundles then checking for state, then passing to case statement.  Don't find it to be ugly or nightmarish.  It has serious potential to simplify code. Programmer would need be responsible in conditions where multiple values could be true.  Jack makes a good point but in most cases I am only trying to evaluate a single value.

[JackDunaway]

Don't get me wrong, I really like the idea, but we all need to resist the evil urges!! If I were to receive this powerful feature, I would want it to become more and more powerful... just being able to enter one comparison would not be enough... I would want to be able to enter complex conditional structures. So that's the slippery slope we need to stay off of.

From here, I must refer you to the sage wisdom of Root Canal for what you're asking for if NI were to consider implementing this idea.

Message Edited by JackDunaway (mechelecengr) on 09-22-2009 11:02 AM

[CantankerousBullMoose]

I think there are some ways this could be polished that would make it a little more in line with NI style and architecture philosphies.  If you wired in the cluster, and then just attached a selector for which cluster element the case structure would use (it should be one global setting for the whole case structure), then the functionality of the case structure itself wouldn't have to change; it would accept a few scalar values in a polymorphic kind of way, and you could gray out those cluster elements which were not appropriate to use as selector inputs.  Bonus points for handling nested clusters using dot notation.  Something like this:

It might not be quite as visually clean as a text description in the case selector dropdown, but it has the advantages that

1) it enforces the use of a single cluster element to key the case selection, so the core functionality of the case selector doesn't change
2) it matches the style of Bundle/Unbundle by Name, and keeps information in "Block Diagram Format" rather than pushing us towards text-based programming

One other note, it seems at first like maybe there aren't so many usecases for this, but one big one I could see would be extending the special Error Handling case structure to be able to key off of the error code instead of the error status.  That by itself seems like it could make the idea worthwile.

[AristosQueue (NI)]

Speaking to the idea of making the ring more graphical and less text:

What about a drop ring that is populated by controls and/or FP terminals?