LabVIEW
Array of clusters that has an array inside the cluster
In all my years of LabVIEW i have never run into this behavior, probably because i have never had to have a an array of clusters that has an array inside of the cluster.
The problem i am having is that when VIEWING the cluster array and incrementing the array elements to view the contents, ALL the other arrays inside all the clusters increment as well.
Maybe i have just never noticed or have never had the need to have this type of control or maybe its a LV 23 thing but it seems odd that this would be how its supposed to work.
Just odd behavior. Maybe someone can explain it.
Oh and if you are wondering why i had to this its because of how a JSON packet is structured. Maybe you know a better way.
{
"Hostname":"host",
"IP Address":"192.168.1.25",
"Control Port":9788,
"Location":"field",
"Range (m)":400,
"Sensor":"acA2040-90uc",
"Lens":"Sigma 600",
"RTSP":true,
"Raw":false,
"Memory Remaining (GB)":2000,
"Disk Size (GB)":3899,
"Hardware":[
{
"Name":"some Controller",
"Control Port":9789,
"Capabilities":[
{
"Name":"Focus",
"Commands":["+", "-"]
},
{
"Name":"Zoom",
"Commands":["+", "-"]
}
]
},
{
"Name":"Gimbal",
"Control Port":9780,
"Capabilities":[
{
"Name":"Home",
"Commands":["Go", "Set"]
},
{
"Name":"Pan",
"Commands":["Left", "Right"]
},
{
"Name":"Tilt",
"Commands":["Left", "Right"]
}
]
}
]
}
Hi Joe,
That's perfectly normal, as an Array control only has a single instance a control representing all its elements. So when you change a property either manually to one of the elements (e.g. by scrolling) or programmatically through the array's Element refnum, this applies to all visible elements of the array. This may look counterintuitive, but that's the way it is implemented. I think NI did not want to have an instance of control for each element because it would take too much space in memory.
Regards,
Raphaël.
Hi Joe,
@Joe_H wrote:
Just odd behavior. Maybe someone can explain it.
No odd behaviour, but expected!
General rule: in an array ALL elements share the same properties, they only differ in value.
So when you change the index value in one of the arrays inside the cluster, then in all other clusters (as elements of the bounding array) the same index value will change. The index value is a property of the array and not its value…
I expected that to be the case just had never ran into it before. Makes for a bad UI design when you can have an array of clusters and change ANY element in those clusters and it does not effect the others but when you add an array to the cluster everything goes downhill.
Oh well such as life.
Got any other ideas of how to display this. Its a monitoring app for some hardware. Could be from 1 -> 15 different cameras.
As long as you do not provide your control saved for LV2021 (max), we cannot see anything.
My opinion is a bit different. it is odd, but it's also expected. It's annoying to me, but I live with it because it is LabVIEW being consistent.
@Joe_H wrote:
In all my years of LabVIEW i have never run into this behavior, probably because i have never had to have a an array of clusters that has an array inside of the cluster.
As has been said, the scroll position is a property and thus shared among all elements of the array. While it is perfectly OK to have such a complicated data structure, it should live mostly on the diagram, not on the front panel, because it is difficult to process by the user, scrolled or not. (I assume this is an indicator, not a control, right?). Maybe you could write a small SubVI that processes it for display, e.g. in a table or even tree structure.
For viewing, i'd use a cluster with individual arrays. If the number of arrays is more than the number in the cluster you'll have to implement a scroll bar and update the arrays accordingly.
