LabVIEW
Generating an array of main menu front panel control refs for passing to subroutines
id wrote:
Darrin the VI you showed me creates an array of Gobject refs rather than control refs. How do I get the GObjects to the more specific class without individually defining them?
quoting myslef from above;
After fighting with that for a while you may want to look at my bundling solution again. 
You will have to cast them as the appropriate type.
In the Nugget I linked in reply #4 you will find a dicsuion that shows you how to cast a ref to a specific type. Here is a preview from that Nugget
So how do you know which type to cast each too once you get them?
Again in that Nugget I showed this image
where I used a trial and error approach to find the proper types.
But all of what I presented in that Nugget as well as what I have been posting above COULD suggest that the clustering method, since it brings with it both descriptive names as well as the data type of the controls/indicators ends up being advantageous.
So...
I have been answering the achademic questions in the hopes of leading you too a more expediant approach.
It's your game in the end so whichever approach you choose remember to HAVE FUN!
Ben
Ben is speaking from experience, I am speaking from "I haven't actually done this, but if I were going to this is how I would do it." As such, I am still scratching my head a little bit. If it were me, and I was building an event handler in a subVI I would
1) Pass the main VI reference to the subVI
2) In the SubVI traverse the Front Panel using the VI I mentioned
3) Use a for loop to convert the GObject references to Control References
4) Pass the Array of Control References to Register For Events with Value Change
5) Build the usual While Loop Event Structure and wire the Dynamic Event Reference to the Dynamic Event terminal
6) Inside the Value Change Event wire the CtrlRef to a property node to get the label text and pass that to a case structure
7) Inside the case structure, create cases for the different labels you care about. If the Control labeled 'X' changed, call the subVI you want. Based on the name of the control I assume you know the type and can use the Value property and Variant to Data to pass the value to the subVI
😎 I would make sure one of the controls is labelled "stop" which stops the while loop in the subVI
This clearly is a one-off solution and subject to the usual caveats of changing labels on the FP requires modifying the subVI. For me, I can count on one hand the number of times I would be doing this so making the leap to the universal method does not make sense. If I ran out of fingers and toes to count on, then it might make sense. It is really up to you as to how many times you will be doing this.
Ben writes nuggets on these things and uses LV daily. I use it less frequently and fly by the seat of my pants. Think of it this way, you have to cut a piece of PVC pipe. I have given you a string and showed you how it can cut the pipe with a little work. Ben is showing off his reciprocating saw. How much pipe will you have to cut to recoup the investment? More than a couple, but at some point it makes sense. Bad example, I would carve my Thanksgiving turkey with a reciprocating saw if my wife wasn't looking, and in my mind one piece of PVC is enough of an excuse to get one. You get the idea, maybe I'll come around to Ben's way of thinking now.....
(BTW: On aversion to the bundling method is that for me it induces flashbacks to early LV days when I had to use an obnoxious stack of local variables to save and restore the control values. I guess I am not quite ready to have my code look like that again.)
Darin.K wrote:Ben is speaking from experience, I am speaking from "I haven't actually done this, but if I were going to this is how I would do it." As such, I am still scratching my head a little bit. If it were me, and I was building an event handler in a subVI I would
1) Pass the main VI reference to the subVI
2) In the SubVI traverse the Front Panel using the VI I mentioned
3) Use a for loop to convert the GObject references to Control References
4) Pass the Array of Control References to Register For Events with Value Change
5) Build the usual While Loop Event Structure and wire the Dynamic Event Reference to the Dynamic Event terminal
6) Inside the Value Change Event wire the CtrlRef to a property node to get the label text and pass that to a case structure
7) Inside the case structure, create cases for the different labels you care about. If the Control labeled 'X' changed, call the subVI you want. Based on the name of the control I assume you know the type and can use the Value property and Variant to Data to pass the value to the subVI
😎 I would make sure one of the controls is labelled "stop" which stops the while loop in the subVI
This clearly is a one-off solution and subject to the usual caveats of changing labels on the FP requires modifying the subVI. For me, I can count on one hand the number of times I would be doing this so making the leap to the universal method does not make sense. If I ran out of fingers and toes to count on, then it might make sense. It is really up to you as to how many times you will be doing this.
Ben writes nuggets on these things and uses LV daily. I use it less frequently and fly by the seat of my pants. Think of it this way, you have to cut a piece of PVC pipe. I have given you a string and showed you how it can cut the pipe with a little work. Ben is showing off his reciprocating saw. How much pipe will you have to cut to recoup the investment? More than a couple, but at some point it makes sense. Bad example, I would carve my Thanksgiving turkey with a reciprocating saw if my wife wasn't looking, and in my mind one piece of PVC is enough of an excuse to get one. You get the idea, maybe I'll come around to Ben's way of thinking now.....
(BTW: On aversion to the bundling method is that for me it induces flashbacks to early LV days when I had to use an obnoxious stack of local variables to save and restore the control values. I guess I am not quite ready to have my code look like that again.)
Darin,
I appreciate the sweet-talking, don't stop! 
I try to keep my code modular since my customers take over the code support adter I am done and its a bad idea to piss-off your customers.
The image I showed above where just the controls used in a single mode of operation there are a couple more that you don't see in that image.
THe modularity extends down into the modes so I will typically use a sub-VI to support the GUI while running in that mode.
This image show the sub-VI for the "Analysis Mode" of operation.
So I can look at this diagram and quickly remember which controls are handled in this mode.
AS always I'm here to help (if you want it or not),
Ben
