Updating controls in a cluster programmatically (or update cluster controls from arrays of labels and values)

[xfrmrs]

Hi folks, 

I am constructing is a way to programmatically update values in a cluster of strings.  The catch is that there are several thousand of these in the end, so besides not being a fan of brute force approaches, hardwiring them is not only unmaintainable, but also would be a nightmare to debug.  The labels for the controls in the cluster are such that constructing them dynamically is manageable and that part works fine.  I then made references to the controls and, well, the reference is fed into the property node at the left side of the block diagram in the partial image shown below.  From there ....

I have a control which is a cluster of strings (a reference to which is coming in from the right in the partial image of the block diagram below). 

I have an array of labels (strings) which match the labels of the strings in the cluster.

I have another array of values (floats) which need to be stored in associated control in the cluster. 

The value and label arrays are indexed the same (enforced by virtue of the way they created). 

The correct control in which to store the associated value is identified by matching the control label to the label array.  The value of the same index in the value array is then stuffed into the matched control.  At probes 6 and 9 in the block diagram image, the control (the cluster of string controls) on the front panel shows the values as being inserted (first front panel image below) as expected.  So far, so good.  

... until we step out of the outer loop (get to probe 8 in the block diagram image), at which point the control values in the cluster are all set to 0.000, immediately when we step out of the outer loop (second front panel image below). 

Any thoughts as to why (or a better way to update a cluster of strings from a list of programmatically generated labels?

[GerdW]

Hi xfrmrs,

look into using maps or sets.

Or use Variant attributes (as was used before maps and sets were available)…

They all implement "key-value tables"!

Do you really need those clusters of strings? What is their purpose?

(You know we often ask "what do you want to achieve" and not "how do you want to achieve it"…)

[xfrmrs]

(yep, I do - "what" questions are the best!  🙂

Do I _need_ Clusters of Strings?  No, what's needed is to populate (fillable) PDF forms, it's all about automated reporting  

Whether a Cluster, Map or Set, the actual problem remains; to programmatically populate one of a set of controls (of which each is a group of controls, with minor but significant variation based on the type of thing tested) given a list of dynamically generated labels..

The clusters of strings came from a preexisting JSON parser.

If I get up to it, which is to say, if this monster can't be fixed, I may reimplement the JSON parser to use Maps instead. 

The scenario (or, how we got here):

There are several variations of an assembly to test.  The data gathered, though similar from one assembly to the next varies by two orders of magnitude from the assembly with the fewest to that with the most tests.

Starting with a (fillable) PDF form, extract the form fields.

Save the (dictionary, in this case, as I used Python to extract the fields) as (something - I choose) a JSON object.

Parse the the JSON object into a LabIVEW (something - here's where the Clusters of Strings came to being - the JSON parser from which I started parsed the JSON as such - though a Map would certainly be a natural :)..

Once all that is automated, then, botta' boom, botta' bing (i.e., do some testing and gather some data), populate the (fillable PDF) datasheets from which the structures were originally generated.

Programmatically constructing the labels for the PDF fields (based on the select assembly) is simple (not to be confused with easy).  However, populating the LabVIEW structure, whether a [Cluster of, e.g., Strings, Map, or Set] when the field names are know only at run time is the actual issue at hand.

Regards, 

Thom

[altenbach]

---

@xfrmrs wrote:

The correct control in which to store the associated value is identified by matching the control label to the label array.  The value of the same index in the value array is then stuffed into the matched control. 

---

Controls are for user interactions, not to "store" data. The wire is the data, so keep your cluster in a shift register and update as needed, then update the indicator if something needs to be shown to the user or pushed to an output terminal.

We typically do much better with an actual VI containing some typical default dataset (e.g. as shown in your picture) and a description of the desired output. Your images are confusing because they are not labeled.

Why are there two different front panel pictures? Why are they different? (is one "before" and one "after", which one?). We can guess, but we might be wrong.

Clusters and their element names are fixed at compile time, so jumping through all these flaming hoops getting labels is just crazy.

I agree that a MAP is probably what you want.

What should happen if a value already exists?

Why is it a "cluster of strings" when it seem to contain all numeric data?

I am pretty sure that properly implemented, there is no "monster", just some simple and elegant code that would probably fit on a postage stamp. 😄

[xfrmrs]

Hi allenbach, 

The irony in the last line of your post is cute, was it intentional? 

It seems the problem statement was lost in the detail.  Simply put: 

Why is the data being set to 0.0... when stepping out of the outer loop?

The bigger picture question seeks approaches to updating a data structure containing data fields with labels known only at run time which are less expensive than the (n log n) current implementation.

The suggestions by GerdW addressed this question well, and will accomplish this task elegantly, though whether this eliminates the original issue remains to be determined.

Indeed, while the labels for the data fields in the individual data structures (clusters, in this case) are known at compile time, which data structure to be updated is determined only at run time (based on the test being conducted).  Though only one is shown in the front panel images, there are many of these in the application.  Each of the many data structures has a similar but distinct set of data fields.

Generating each case completely can be done, and doing so would enable your suggestion to keep the cluster(s) in a shift register, etc.  However, here are literally thousands of cases and potential for more in the future. Such an approach is not easily scalable nor maintainable.

In lieu of brute force, the names of the fields to be updated need to be generated at run time.

[altenbach]

---

@xfrmrs wrote:

Hi allenbach, 

The irony in the last line of your post is cute, was it intentional? 

It seems the problem statement was lost in the detail.  Simply put: 

Why is the data being set to 0.0... when stepping out of the outer loop?

---

You have a string wire coming out of nowhere on the left, entering a pyramid of loops, and exiting unchanged (As far as we can tell, because some tunnels are hidden under probes). I assume that the wire value is 0.0 from the beginning but I won't debug any truncated blurry pictures. No point in that. 😄

Please attach a simplified version of your code (all controls with reasonable defaults, code reduced to the problem section, clear explanation what result is expected, etc.) 

 

[xfrmrs]

Hi allanbach, 

My bad, it seemed obvious that the wire is passed through the loops only to enforce flow control,  I'll be sure to address such as that in the future.

As these things often happen, I've found the issue in thinking it through, making that your assistance isn't required rather convent. 

Take care and thanks for playing....

[xfrmrs]

Hi GerdW, 

The variant attribute approach is a brilliant recommendation.  Thanks for the reference.

[altenbach]

---

@xfrmrs wrote:

The variant attribute approach is a brilliant recommendation.  Thanks for the reference.

---

IF you have LabVIEW 2019 or newer, please use Maps instead!

(see also my presentation from NI Week 2019)

[xfrmrs]

HI allanbach, 

Doing so is worth considering, and worth doing if there are significant advantages to using maps over the cluster of strings.  I'll have a look at the video after a bit, but if there are there significant advantages to using maps over clusters (i.e., for the particular issue of needing to update data structures wherein the data-field labels are not known until run-time), perhaps you can post the bullet list?.

II am correct in my understanding of a map as similar (if not identical) to, e.g., a dictionary in, e.g., Python, or a hash table in, e.g., C, I concur that maps are more appropriate, and certainly more similar to the JSON structure from which the data structures are created, and likely easier with which to work than clusters.

There are resource cost considerations with changing the data type. These matters could certainly be worked out but doing so may not be worthwhile after considering the expense required to do so.

To recap the detail in my second post in this thread, the exercise is to auto-populate one of several data sheets, depending on which of several tests is conducted.. 

Ultimately, the data gets pushed to a (fillable) PDF form.  These forms get changed from time to time (our products are around for generations). 

For new/updated datasheets, the application automates the extraction of the (named) fields from the PDFs as JSON 'objects'. Since the fields in the PDF are all strings, the untyped JSON 'object' is a collection of strings..

The JSON is then parsed in LabVIEW and stored as type defs.  The LabVIEW JSON parser converts 'objects' to clusters, thus generates clusters of strings (because the fields in the PDFs are not formatted in the first place.  To have it create maps would require rewriting it to do so - not a problem, but resource intensive.

Without re-writing the parser to create maps, we could create a virtual instrument to convert the cluster of strings to maps using the variant attributes, but we don't know the expense of that, either, bringing us full circle to the top of this post....