Cluster Unbundle Input for Bundle primitive.

[smmarlow]

Sometimes large clusters need to be 'rebundled' with one or a few elements added to make a new cluster.  Currently, the programmer has to completely unbundle the entire cluster and wire all of the elements to a bundle function with the new element(s).  It would be nice if there was an "Unbundle Input" option for a Bundle input that has a cluster wire to it.  The Bundle function would unbundle the cluster at the input and add all of the elements (in order, of course) to the new cluster.  It would only unbundle on level.  That is, if the input cluster has a cluster in it, the lower level cluster would not be unbundled. When the proposed  'Unbundle Input' option is selected, the input terminal changes to a standard unbundle arrow graphic to indicate the input cluster is being unbundled. 

[altenbach]

I don't understand how your proposed node should be able to distiguish which one of the orange wires is to be rebundleded?

In any case, proper code uses bundle by name, in which case we simply wire the old cluster to the top and rebundle the selected single element.

Trying to use a plain bundle (= not bundle by name) seems to obfuscate more than I would like.

EDIT: Ah sorry, you are making a new cluster, containing an extra element. That's slightly different....

[smmarlow]

@altenbach  Yes, it is a new cluster with an additional element on the output side of the bundle function.  My graphic should have been more clear.

[smmarlow]

Perhaps this graphic is more clear:

[Mark_Yedinak]

I guess I don't see the usefulness in this feature primarily because I rarely (if ever) use a cluster that is not a typedef. As Christian mentioned good coding standards dictate the use of bundle/unbundle by name. I did see that you were creating a new cluster but I am not a big fan of defining data on the fly. Without the typedef it is far to easy to misalign clusters and write data to the wrong element.

[RavensFan]

I'd agree with Mark on this.  If the boolean was important enough to be included in the cluster at the end, it is important enough to be there all along.  Even if the boolean has no particular meaning when the original data in the cluster is established then I would just ignore the boolean element until I later know I've defined the value of the boolean through a Bundle by Name.  I think have a set of like data that only includes some of the data at one time, but includes more data at a later time just adds confusion as to what data actually belongs together.

[mattjsimps]

I like it, but cant you do just that with bundle by name instead.....? Actually, how can this work? It cant distinguish the element just on type.

The winner for me though is the tidier wiring with the cluster input on the left rather than top - maybe the current bundle by name should be redesigned to look like this.

[tst]

Matt, look at this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Property-Node-Style-Bundle-and-Unbundle-Element/idi-p/...

[smmarlow]

Thanks for commenting, everyone.  

@Ravens Fan & Mark.  I agree that typedefs and the bundle by name feature are the hallmark of good programming practice, and use them for almost all of my data definitions (as well as lvoop classes).  There are occasions where smaller typedefs, clusters, and various other data must be aggregrated into a larger cluster.  In some cases, that larger cluster may only exist in a single place.  In these cases, I have defined data 'on the fly' without typdefs.  While these occasions are admittedly infrequent, they are a pain.  But having read your thoughts on the matter and re-thought it some, I have decided the frequency of these situations is not enough to warrant the feature, and could encourage poor practice in the wrong hands. I therefore withdraw the idea.

[G-Money]

Functionality might allow for improper programming practices. Typedefs of clusters and Bundle By Name are a better way of achieving this functionality in LabVIEW currently.