LabVIEW
How to handle 40 of the same little GUI's - Part 2, references to controls
As the title suggests this is a follow-up question of my post a few weeks back, see LINK (opens in new window)
The given solution works great ..... but I would like to be able to have references (in an array) to the start and stop buttons so I can use property nodes to enable\disable them and maybe change the color. I tried 'everything' 
but I just don't seem to be able to get it. I could get the references to the array elements (clusters) but not to the controls inside the cluster.
Hope somebody can guide me in the right direction, thanks.
Attached is an example written in 2015 that gets a reference to a cluster, then gets the booleans in that cluster, and then sets the color of one of them.
Floris wrote: but I just don't seem to be able to get it. I could get the references to the array elements (clusters) but not to the controls inside the cluster.
Be warned that all elements in an array must look the same. So a change you make to the cluster will update all of the clusters visible in the array.
Good point, I forgot that you want this cluster in an array. So disabling the one button will disable all of that button in the array. That is why (now that I re-read the old thread) I suggested using a color box control to change the color of each one. For this you could try to do something similar but I suspect you will run into issues. There are other options but all are terrible. You could use a 2D picture control as your button, and the value of that image can be any button you want, visible, hidden or with other colors. But then you need to write code to detect mouse clicking in the event structure. Even if you set a color box control to the transparent color, it doesn't let you click through it, and just sets its color to the pane's.
The easiest solution for disabling a button is to not disable it, and just have a dialog telling the user you can't do this right now. Like Start when it has already started.
@Hooovahh wrote:
Good point, I forgot that you want this cluster in an array. ...
This spoiler will not help with this discussion, but I do like bending the rules and going where no worker has gone before.
We can not put subpanels in an array but we can put them in a cluster and then make the cluster look like it is an array.
With no sub-panels inserted it can look like this.
After inserting our selection of diverse sub-panels it looks like this.
Scrolling we can see what looks like dissimilar objects in an array.
Theory:
Start with a cluster that has a scroll bar control and a bunch of sub-panels. More than will ever be visible at one time.
Size the scroll bar to fit the cluster.
When loading the "dissimilar array, insert the sub-VIs into the sub-panels and size the sub-panels and position them inside the cluster, working our way down the cluster. Only load as many sub-VIs as you have sub-panels.
When the scroll bar changes values, readjust the position of the sub-panels inside the cluster.
As sub-panels scroll off the top of the screen, unload the sub-VI that was in it, put the next sub-VI into the recently freed up sub-panel and position it at the bottom out of sight.
Scrolling up and down uses the same logic.
It like watching a cartoon character walk across a pond using two lily pads and picking up the one behind and dropping in front to take the next step. Virtual memory in a computer works the same way.
After thinking about Bugs Bunny stop and ask yourself, "How does LV handle an array as it scrolls values ?"
Not saying it the same process but it may be.
Ben
Oh yes here is a good example of a Virtual MCLB that was used to optimize large tables with lots of custom coloring. I've done the same concept on UIs with clusters, where I only want to show N of them, not N+1. Having resizable UI's complicates things a bit, cause now you need to determine how many clusters to show, and based on that how large the scrollbar is, etc.
I like the subpanel cluster concept but certainly there is a lot of extra work involved in keeping track of things. I don't mind doing it as long as the user has a good UI/UX at the end of the day, but it certainly is alot more work than probably OP wants.
I'd say the better solution is to register User Events in these GUI's so you can send commands to them, e.g. "Disable:[controlname]" and each VI disables it's own control. It's easy enough to create 1 User event for each, or have 1 for all (which'll then require some filtering or adressing in the commands).
/Y
