Strange Array Behavior When Getting Values

[jmrapp1]

I understand that, the point is this needs to be dynamic and reusable so that if something changes largely in the future there will need to be minimal changes. That is the reason that the VI I am using takes a Control reference. It's planned to be used in many projects so I'd like to try and make it completely dynamic rather than have to create a new separation for every array in the future.

[aputman]

No offense but I think you are biting off more than you can chew without having even a basic knowledge of indexing arrays.  There are toolkits already available for writing control values to files, and ones that are even recursive.

[Ben]

I will save you a lot of work by sharing this link to an old Nugget I wrote about doing exactly what you are attempting.

The code I posted looks like this

And is cpable of data like this.

And will not work without this Rube-Goldbergish code construct.

I provided code and a discusion of the challenges to do what you are atempting to do.

After you get done reading that Nugget and looking the code I think you will opt rading the value of the control s a variant and after casting as the correct data type, just indexing out the element and filed you want to get at.

Edit

The issue you are seeing is the element reference points to the cluster elemet that is shown top-left in the array.

Ben

[aputman]

If you want to see how involved this task is, OpenG has a "Write Panel to INI".  MGI also has a "Read/Write Anything to File".  I think you'll change your mind.

Edit: ... and Ben's nugget. 

[jmrapp1]

I think you are missing that I already developed the system that Ben displays above. It reads/writes controls recursively to/from an XML file. It works great except for with arrays because my system takes a control reference as the input rather than a value. The reference is used to get the label names and use them as keys to form the "XML path". The reference is also used so that when we are handling a cluster, it will recursively build the XML into other clusters that that cluster contains (similar to Ben's example). I know exactly how array indexing works, but the way that LabVIEW handles arrays and lets you access them is very restrictive.

Here you can see a cluster that is going to be converted to XML. You can see the results of it through my system.

[Ben · Accepted solution]

---

@jmrapp1 wrote:

I think you are missing that I already developed the system that Ben displays above. It reads/writes controls recursively to/from an XML file. It works great except for with arrays because my system takes a control reference as the input rather than a value. The reference is used to get the label names and use them as keys and form the "XML path". The reference is also used so that when we are handling a cluster, it will recursively build the XML into other clusters that that cluster contains (similar to Ben's example). I know exactly how array indexing works, but the way that LabVIEW handles arrays and lets you access them is very restrictive.

---

In the code included in my nugget I manged to get it to work by defering FP updates (to hide it from user), set array to only have one visable element, set the index to display the array element I wated to look at, then used the element ref to get the value and then restoring the control appearence, and setting the control ref back to where it was when it started.

My point suggesting use another approach is paraphrased by the scientist (played by Jeff Goldblum) in Jurasic Park when he said...

"It is not a question of COULD we do it but rather SHOULD we do it?"

Therea are better ways if you will allow for a limited amount of coupling between the code and the type def.

Ben 

[jmrapp1]

Thank you! That was exactly what I needed, I simply changed it to only show one element at a time and it works like a charm.