update value within array of cluster

[r_exler]

Updating a value within an array of cluster is too complicated compared to other programming languages.

In my application I hold an (global) array of jobs to do, each consisting of its name and an array of (different) parts belonging to this job. One element of the part's description is the number of parts already done. If I want to update this value, the code looks:

Note the calling function has to update the global variable after updating or JobFilesIn and JobFilesOut can be replaced by reading/writing the global which does not make the code more visible.

Within C code the update would look

JobFiles[JobFileIndex].Parts[PartIndex].Done=Done;

which will not raise the need of making it a function (VI) at all.

A solution might be similar to Replace Array Subset if the compiler is parsing the data type on the input and accepting indices and cluster element names as shown below

Of course this should work with any data type selected from the initial variable by the selectors similar to C code

variable[index].element=array;

It also should accept a cluster as top level element as well, e.g. to replace an element within an cluster of clusters similar to C code

variable.element.subelement=WhateverDataTypeThisIs;

or an element within an array which is part of a cluster.

variable.element[i]=WhateverDataTypeThisIs

All the C code examples above expand to LabVIEW code which is hard to read.

[AristosQueue (NI)]

Have you seen the inplace element structure? It greatly cleans up the code that you're showing here.

(I am not saying you're proposing a bad idea; I'm just pointing out something that should help you in the short run.)

[GregSands]

Here's a similar request based on the In Place Element Structure:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Nested-In-Place-Structure-Chain/idi-p/1094273

The problem with the IPES is the horizontal space used - I like your suggestion of a Replace Array Subset modification, although the enums might be a problem if the cluster changed - perhaps a pop-up on the node itself?

[r_exler]

Some notes to the posts above

a) Thanks for the tip using the in place structure. In fact using this the code looks somewhat better, but still complicated compared to text oriented programming languages:

b) Another suggestion to implement is to consider the arrays being similar to a regular member of a cluster, but adding an index input. The graphical display will be like a bundle by name and can replace any element within a nested cluster/array combination.

With the selector display:

[X.]

What about a node similar to the Index Array/Insert Array Element where instead of an index value, you would have a string specifying the access pathand as many parameters as needed for the different subarray indices:

(the format specifier should read Parts[%d])

[AristosQueue (NI)]

X: Such a node is of course possible, but being specified as a string means it doesn't break when the structure of your data changes, so you'd have to add an "error out" terminal. If we created such a node, I'd rather see some sort of structured constant (I have no suggestions at the moment as to how I would present this on the diagram) that can be checked at compile time to verify that the field you're specifying actually exists. The "string input with run time error out" node could be useful in some situations, I just don't usually like to code with such reflection APIs as they tend to be fragile vis-a-vis code changes. I wouldn't oppose it if G gained such a node, I just would avoid using it myself most of the time.

[X.]

Of course you could also pass cluster element names as in:

Array[%d].Parts[%d].%s

where %s would be "Done" in the example above.

An error in and out would be needed indeed.

[GregSands]

X, your suggestion seems pretty close to the Variant Data way of accessing clusters, but will have the same problem that it won't know what type the Set/Get Element should have. That's why my preference, and suggestion above, is for a node-based configuration - once you've wired the ClusterArray, the node knows all of the data names and types, and if those change, then you get a compile-time check rather than a run-time check.

[Chris_Cilino]

All,

A few years back I posed the idea of the LabVIEW Container. In effect, it is a dynamically generated and edited cluster. Here's a link to a short video walking you through my idea. Hoooovah has aslo come up with his variant repository which is very similar.

Given the nature of this discussion, I thought it might be good food for thought.

[X.]

I kudoed Chris_C's idea at the time, although I never used his API.

I agree with GregS that an implementation that would preserve type would be much preferable (and therefore it would have to work at compile time). The advantage I could see in the format string approach is that this is a syntax which is very similar to text-based languages with which most of us are familiar (and we use in LabVIEW anyway when handling strings). I am afraid that an expandable node with mixtures of array indices and cluster element names would be very rapidly confusing...

[Sam_Sharp]

A good idea, I like it. Not sure which of the proposed suggestions I prefer but there should definitely be an option that preserves the type like a bundle/unbundle.

I too often have to create SubVI just for manipulating a cluster because of the space the operation takes up on the block diagram.

I think clusters relate very closely to XML/JSON containers/formats - nested named elements/arrays. With text based languages XML/JSON, you can specify a 'path' to the item (XPath for XML), something similar to MyCollection.Items[X].Property and set/get the data that way which is a lot simpler than the equivalent in LabVIEW!