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.

[Intaris]

The suggestion to have a run-time parsed accessor string I would probably never use.  I like my errors at edit time, not at run time.

I would, however, greatly welcome the ability to define IPE elements which allow direct access to "Array[i].Index.Maximum" for example.  Having to always have multiple IPEs to drill down more than one level of a data hierarchy is often awkward. even though modularity would probably dictate that separate structures is better.

There MAY be performance issues to consider: In cases where we try to access an array index which is not actually present (a rare case where an IPE can cause a buffer allocation) the need to allocate an entire array element (perhaps the cluster in the array is large) can be very costly.  If we only then need to have a temporary copy of the single element then the impact of such an incorrect array index is greatly reduced.  Unless of course the LV Compiler already does exactly that for nested IPEs in which case, just go back to ignoring me please.

[X.]

Who said that the string parsing would not generate errors at edit time? It could behave like a formula node (or rather Expression Node), breaking a wire if the syntax is incorrect (or there is a missing argument, as for Format to string).

.

[Sam_Sharp]

I think Intaris is referring to if you were to dynamically specify the path string at runtime. While that's something he hasn't used - it is something I have used (and seen used by other developers) quite a few times. One developer parsed the cluster into XML, did a find and replace and then converted back from XML and I've more recently used some of the MGI cluster tools to do the same thing.

[X.]

OK, so that's probably a misunderstanding of what I had in mind.

I did not think of using a "string constant" object (which in this case you could indeed have been able to  replace by any string wire connected to any string source and that means you could have any random string at runtime).

I was simply thinking of the Format to String syntax (typed into an object similar to the Expression Node, which you can only modify at Edit time), in order to simplify addressing the element of interest.

[Oligarlicky]

I like the GregS implementation. I also want it for indexing.

[X.]

The problem with "blocks" is that they can get HUGE if the elements names are not concise (think about some Property Nodes) or if the structure is very nested.

And, this is personal bias, I just can't think straight with broken down structures such as the one illustrated in GegS's comment.

Of course, a "Format String" object would have to be resizable (like a... string constant), use autocompletion with keyboard shortcut, etc.

[Intaris]

I don't say that the idea of having a string input for defining the items to access is a bad idea per se, it's just not one I'm personally craving for.  It would probably be widely and well used by others, so this wasn't meant as a "downvote".

If the selector is a fixed string input as part of the node as opposed to a string constant (which could lead to run time errors by dynamically specifying the element to access) then the picture is very different and this is something I would certainly support but I'm not convinced ont he resizeability of the strings used for the definition.  This seems like bad information hiding.  At least the IPE solution is immediately visible as to what is going on and you can "outsource" each hierarchy level of the access to an inlined sub-VI.

So how to address the visibility of which parameter we are accessing when the entire access path is long?

[X.]

I was not thinking of hiding anything, just resizing it so that you don't end up with a very long string.

JobFiles[%d].Parts[%d].Done

could read:

JobFiles[%d].

Parts[%d].

Done

or

Job

Files

[%d].

Parts

[%d].

Done

etc.

The first alternative makes it very similar to the expandable node suggested by GregS, but as far as I am concerned, requires less mental gymnastic to figure out what elements are referred to. I exposes the whole underlying structure of the object much more clearly (for me).

[GregSands]

I agree it could get unwieldy with elements with long names, although that is already the case - just look at the IPES examples above which repeat that name twice! But I still prefer a node-based configuration rather than a wired input, which disconnects the definition and the structure. Perhaps an easy way of defining the node is that clicking the node pops up a tree-like description of the structure, and the programmer simply clicks on the desired element to be accessed, and the node is then configured with the necessary inputs and outputs to do that. The node could certainly be a lot less compressed than my first example, which was just a cut-and-paste - more room around each section would aid in seeing how the structure is being accessed.

[X.]

I think I am misunderstood.

In my mind, the "format string" is not separate from the node itself.

It should be resizable, as a format string should, but it should also "auto-complete" and the whole thing should "break" the VI if the associated node is missing an input (or has too many).

Think of a polymorphic VI selector on steroid.

You can move the selector (but can't resize it) and modifying it (choosing from a pull-down list) results in node changes:

======>

=======>

I am mostly concerned with readability. Sometimes, all graphical is not the way to go (but sometimes improvements are possible, see this suggestion for multidimensional array indexing) .

Not being able to resize nodes such as the bundle and unbundle ones may result in choosing abbreviated cryptic element names, which NI does. See for instance this Graph Legend property, which reads "Plot Visibility Checkbox Visible" in both the contextual menu and context help:

but shows up as "PlotVisCheckboxVis"in the actual property node:

Note: the notion that LV's node design leads to crazy large diagrams has been addressed in the past:

Fluent Interfaces with Method Chaining for Objects (especially .NET)

with a very similar look to what is proposed by GregS (check my comment at the end though...)

... which might very well be identical to this proposal by SteveChandler:

Property Node Style Bundle and Unbundle Element (which I kudoed!).