Initialize several Top VI controls from initialization subVI

[EMCCi]

Hello everybody,

I'm trying to design an initialization subVI for the GUI of my top VI, but I'm not being able to create an array of refnums with the controls of the front panel that I want to initalize to pass it to the subVI.

Then I'm doing it like this right now:

Top Level VI

Initialization SubVI

Updating the controls, via property nodes and local variables, in the top level diagram because I can't create arrays with the top level FP controls that I want to pass to the SubVI. There is a cleaner way to do this?

I have read about the pane property node "controls []". But I don't need them all, and I need them in a certain order. I think it can be very tricky to sort and select the useful ones.

Best regards and thanks for your time,

EMCCi

[Norbert_B]

---

@EMCCi wrote:
[...] There is a cleaner way to do this?[...]

EMCCi

---

Yes, there is.

- Split up data and GUI

- Update the data according your configuration

- Trigger an update event for the GUI which is reading the data and displays it

Should be implemented using producer/consumer or derived architecture.

[thols]

---

@EMCCi wrote:

Hello everybody,

I'm trying to design an initialization subVI for the GUI of my top VI, but I'm not being able to create an array of refnums with the controls of the front panel that I want to initalize to pass it to the subVI.

You cannot put the reference controls into an array constant. Use build-array.

[Bob_Schor]

Doesn't this create an array of refnums to all controls on the Front Panel?  I've seen this, but don't think I've ever used it ...

All Controls on FP?

Bob Schor

[Ben]

Here are some links that may give you ideas.

Exploiting Control References Nugget.

Granted LV has come a long way since that Nugget from 12 years ago but it does offer some insight.

The images in this album show one case where I talked bout a GUI controller. I wrote about it in this thread.

The key to get this to work in an elegant manor is to use a Type-defed cluster. In this thread I wrote about how to easily create a type -def of the proper type for the control references in this thread.

Sure it can be done using [control] but then you have to bend over backwards to get at the properties of the control that are not generic (visable/hidden) like tht data type and object specific things like chart axis properties etc. Using a typ-defed cluster will let you get at thos toehr properties. If you use an array, all of elements of the array are cast to a single common class so to use them you would have to know what specifi type each reference is in the sub-VI and cast the reference (see that nugget on control references).

Please note that a GUI controller is not readily accepted by all. But for my part, they work just fine provided I am not trying to code up speed record type code. But for initializing things or responding to a user interaction they work just fine.

I should also do my civil duty and point out that property nodes are executed in the UI thread which is single threaded so don't blame me if you get carried away and your GUI is sluggish.

Use them but do not abuse them.

Ben

[proland1121]

1. Create a TypeDef cluster of references (create the appropriate number of references, by control/indicator type, and name them to match the front panel objects).

2. use your refnum constants on the front panel to populate the typedef cluster using Bundle by Name.

3. Now you have a cluster of refnums which (using Unbundle by Name) are associated with front panel objects using meaningful descriptions.

Beyond the initialization step, this cluster of refnums can be passed in to any GUI update subVIs you wish to design... enable/disable/hide/show controls and indicators based on the current state of your GUI.

I like to define 1 GUI DEFAULT state (typically for my IDLE state) and then one for each design state I intend... Initialized, Testing, Error, Saving Data, User Input, Operator Mode, Admin Mode, etc., etc.  Defining each "GUI STATE" as changes from the default.  This way, no matter how many states I have or what order they occur in, all I have to do is set the GUI to Default, and then the Desired State.  Makes for a pretty flexible GUI update scheme.  Note: disabling the "front panel update" before changes and enabling after changes prevents any unwanted flashing/flickering.