accesing controls (references) from several VI's

[_Faust]

Ok I have this small problem:

I have a large program and have put serveral "advanced settings" in a different VI.

Result is that the values entered here need to be passed to controls in different other VI's

The way I use this now is using 1 element queues to pass the control value. 

For one VI I can create control references, call a sub vi and put here the control that can manipulate the value.

How do I achieve this for multiple VI's? Is there a way to make control values from ANY running VI available? Maybe using xcontrols? I have no idea how to achieve this though.

thanks!

[Ben]

I will typically use a GUI controller in my apps to accomplish that type of thing.

GUI Controller

1. I develop an Action Engine  that will cache a cluster of control references when an Init method is invoked. This put all references in a SR that can be accessed from any place the Ae is used.
2. I add methods to the AE to take care of screen settings associated with changes of state ("Set Visability Edit Mode", "Set Visablilty Login", etc).
3. I also add a method to return the cluster of refs so I can use them to set-up dynamic event registration in sub-VI etc.

A side benfit of using a GUI Controller is that you have a single point where you can add a "stack" of screen views so functions like "Back" and "Forward" can be added easily. 

So...

trying using a GUI Controller.

Ben

[JÞB]

Great minds think alike.

Ben's suggestion is nearly identical to how I manage my GUI's and test"option" variables (Facility, Operator, Permissions etc...) I tend to create multiple AE's to limit the AE scope by function or feature (1 AE controls the progress bar and another manipulates the visability of booleans on the UI) but the concept of initializing AEs with refs to controls allows the controls to be controled from anywhere in the project. and User actions can be made available as events directly in the module that is going to react to the event unburdening (and uncluttering) the Main GUI.  Simple modular (and reusabl) code makes the programmers life pretty easy---for the next project.  One Caveat: You will take a penalty in development time for the original project And, if you do not completely think through all cases, you will take another hit in dev time when you first reuse the module.  But the pay-off comes from having a library of solid flexable code in the future.  You need to make this point to management and get them to "buy-in" to the stratigic advantage- or.  Like someone who shall remain anonomous  suffer management's displeasure at your productivity.

Luckilly, I've set myself up to have a "great improvement" on my next evaluation cycle 

[Mark_Yedinak]

---

Ben wrote:

I will typically use a GUI controller in my apps to accomplish that type of thing.

GUI Controller

1. I develop an Action Engine  that will cache a cluster of control references when an Init method is invoked. This put all references in a SR that can be accessed from any place the Ae is used.
2. I add methods to the AE to take care of screen settings associated with changes of state ("Set Visability Edit Mode", "Set Visablilty Login", etc).
3. I also add a method to return the cluster of refs so I can use them to set-up dynamic event registration in sub-VI etc.

A side benfit of using a GUI Controller is that you have a single point where you can add a "stack" of screen views so functions like "Back" and "Forward" can be added easily. 

So...

trying using a GUI Controller.

Ben

---

This an excellent method for achieving what you want. A variation of it would be to use LVOOP instead of the AE. The two approachs are essentially the same but with some thought on the definition of the classes I imagine you can create a general purpose base class to handle most of the common aspects. Customizations can be achieved using derived classes.

Further adding to Jeff's comments about the up front hit in the schedule. When done right you will see the benefits of shorter schedules for future projects. The first time is the hardest sell to management. However once you get a couple of successes under your belt future requests will be much easier since you now have a track record of benefits achieved by using reusable code libraries.

Message Edited by Mark Yedinak on 03-30-2010 08:55 AM

[tst]

I think you're all missing the point. _Faust wants the VALUES of the controls available globally, not to manipulate the actual controls.

There is no single right answer for this problem, but using control references to use the value of the control is rarely a good solution.

Here are some options:

1. Write the values into global variables. If you only have one writer, this is relatively safe, but it has potential pitfalls.
2. Keep all the values together in a cluster (or a class) and share that cluster globally. You can then pass the cluster around using the SEQ concept you used (or, if you're using 2009, data value references, which are more convenient). The advantage of using a class is that you get some protection and an easy mechanism for generating the VIs which read and write the cluster elements. Also, you should note that the values saved into the cluster and used in the code will not necessarily have the data type which you display to the user for configuring the options. Sometimes, you want to have a different type.
3. GOOP. See near the end of Ben's AE nugget. This is basically the same as 2 (and the example I posted there actually uses a SEQ), but has the advantage that you can generate N objects (which is probably not needed in your case).