Allow access to subarray from array of cluster elements by array and dot notation

[jlokanis]

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

[Jim_Kring]

I agree that this is a needed feature.

[altenbach]

This is basically the same idea as this one, except "by name" (See also comment by mech.).

[ooth]

I find myself doing this all the time. This is the very first feature on my list.

[jlokanis]

It is simular to the other post, but I think the implementation I proposed is more complete and follows C conventions so it is easy to understand.

[Intaris]

It's easier to understand if you know C conventions otherwise it's not really.....  I would guess that up to 60 to 70% or LV programmers do not know C conventions.

[crossrulz]

I think readability would be a lot better using this method.  I do this type of thing as seen in your example all the time.  This is a much needed functionality.

[jlokanis]

This type of enhancement is really directed toward advanced LabVIEW programmers.  I would guess that over 90% of them also know some C, C#, VB, Java, Perl or many other languages.  So, the convention of indicating an array with [] would not be foriegn to them. Also, there are many exisiting C conventions already in LabVIEW, such as how you reverence subelements in a cluster using dot notation (topcluster.subcluster1.subcluster2.mydata).  Since LabVIEW is written by C programmers, I have found that almost every component of the C language is represented by a corresponding component in LabVIEW (albiet sometimes with a different name).  A good example is the switch statement in C being implemented as the Select function in LabVIEW.

While I also agree that this enhances readability, I also think there is the opportunity to improve performance.  The removal of the for loop should speed things up unless the compiler already optimises out the for loop and does a direct memory copy of the data with an offset increment to jump from one sub element to the next in the cluster.

I am not sure how a data structure of this type is represented in memory by LabVIEW, but I am sure one of the DEVs at NI can find away to make this faster. 

[altenbach]

Maybe the idea could also be extended to allow the same functionality for the "in place element structure".

In addition to the "unbundle/bundle elements" terminal pair, we could have a new "Index unbundle/bundle element" terminal pair.

This would potentially allow for simplified code dealing with arrays of clusters.

[JackDunaway]

As altenbach pointed out in his first comment, this is an illustration of my comment  under his idea. (I notice that certain people who support this idea have not yet also given due credit to altenbach.) Nevertheless, Kudos, my friend. We want this feature, NI!

[AristosQueue (NI)]

> I would guess that over 90% of them also know some C, C#, VB, Java,

> Perl or many other languages. 

I think you would be very surprised then. Based on what I know of our customer base, I'd put the number down around 30% and wouldn't be surprised if it was significantly less. 

> So, the convention of indicating an

> array with [] would not be foriegn to them.

Wouldn't something more graphic be better? Like adding the glyph for array to the unbundle node?

This is just the first idea that occurred to me... there may be other ways of graphically representing this action that are better. My point is that in a graphical language, we should only fall back on text notation for something as a last resort.

Message Edited by Aristos Queue on 07-01-2009 02:52 PM