Using VI Server to update a number of control properties

[dblk22vball]

I have an application where I have to disable/enable a couple of buttons, update a status String indicator as well as a couple of other indicators/controls.

What I am currently doing is creating a cluster of references to each indicator and control, unbundling the reference that I need, and then using a property or invoke node to update the item accordingly. But this can get to be pretty block diagram intensive (large area) if you want to do this for a large number of items.

I was thinking that it would be easier to just pass around a "This vi" reference, and then use the SetControlValue. This would lessen the number of references that I would have in my cluster.

So I thought maybe I could have an array of the control names on my front panel, and then just update them as needed (only at the start and stop of the program, not a continuous update). But since I would be doing different things (enable/disable, text, colors), you cant really use a For loop (that I can see) to easily step through and update the controls.

So my question is, how you the labview gurus update a large number of controls with different properties at one time? Do you just use the "brute force" of a node for each control in a long string, or is there a way to go through them all easily with a loop?

[Francois Normandin]

So my question is, how you the labview gurus update a large number of controls with different properties at one time? Do you just use the "brute force" of a node for each control in a long string, or is there a way to go through them all easily with a loop?

OpenG's configuration files are your friends...

Use "Read/Write Panel to INI" for the values.

Use the Read/Write Variant in a for loop for the rest.

[crelf]

I use "Write Panel to INI__ogtk.vi" and "Read Panel from INI__ogtk.vi" a fair bit.

OpenG's configuration files are your friends...

Looks like François beat me to it

[Mark Balla]

If I need to save controls settings that need to be recalled later I use the above methods.

But Usually I don't, and for large UIs that I need to guide the user through I will use the method below.

First I scan the Front panel and put all the control refs and label names in a Functional Global.

To set controls I create a list of control names.

Find the index of the name in the FG.

Using the indexes I build a list control refs.

Finally I send the reference array to a vi that changes the properties.

So really all I am doing is changing the properties of the controls by name.

What I like best about this method is it allows me to easily create groups of controls.

By using some creative naming schemes it is also easy to add and remove controls from groups without changing code.

Below is the block diagram for the Top level vi

Inside the Indicator and Button case the code will scan the FP names for the correct prefix and then set the property.

Now If I want to add a button to the FP and want it to be part of the button group I just add Button_ as a prefix

The new control gets its property change at the correct time with no code changes.

If you use the search for prefix method remember to hide the label and show the caption on your Front panel controls.

Here is the code I hope this helps

By the way FPK stand for Front Panel Keeper

FPK.zip

Mark

[Yair]

Personally, I can't stand using control labels to get a link to the control. It creates a hidden link in the code which is impossible to find and very easy to break.

Here are some alternatives:

• You can find a very simple example here of how to bundle references into arrays which serve as groups. You can then act on these arrays as units. Each control can easily belong to more than one group.
• Here you can find a JKI RCF plugin which will allow you to very easily create an array of references for any number of controls you select. You can then operate on these controls by index. This is better IMO than the label method because there's explicit code.
• Here you can find another plugin which will allow you to easily create a typedef cluster of references. This is the one I like the most because the code is explicit, but as you mentioned, it has the downside of potentially taking up a lot of diagram space.
  

[Mark Balla]

Personally, I can't stand using control labels to get a link to the control.

It creates a hidden link in the code which is impossible to find and very easy to break.

Here are some alternatives:

• You can find a very simple example here of how to bundle references into arrays which serve as groups. You can then act on these arrays as units. Each control can easily belong to more than one group.

Any time you place a reference inside FG you have a hidden link.

It looks like from the example they are only choosing to build the ref array differently.

Are you saying you need to have this big ugly bundling of control references on the main block diagram so you are not confused as to what controls get changed?

I find my name to reference method very easy to debug.

Any control that I want to hide or disable will use the top level vi and if there is a problem I go to that vi to fix it.

• Here you can find a JKI RCF plugin which will allow you to very easily create an array of references for any number of controls you select. You can then operate on these controls by index. This is better IMO than the label method because there's explicit code.
• Here you can find another plugin which will allow you to easily create a typedef cluster of references. This is the one I like the most because the code is explicit, but as you mentioned, it has the downside of potentially taking up a lot of diagram space.
  

I like the tools but to me this gets a very low score on scalability.

With this method every time I want to add a new control to the group I have to

• create a reference
• then create a control to that reference
• then copy that control
• open the stub vi
• open the typedef in the control editor
• paste the control ref
• apply and save
• go back and bundle the control cluster.

Or

• delete all the auto created code
• go though the block diagram and find every control in that group (if I can remember them all)
• select them
• run the tool
• reconnect all the broken wires.

And this is for every group I want to create.

Finally if one of the control refs that you are bundling refers to a typedef and the typedef is changed during development.

The reference in the stub vi will no longer match and your code will break.

Keeping controls refs and typedefs in sync is one of the biggest pains in LabVIEW.

So as I see it,

the difference between our approaches is

mine forces the programmer to be more disiplined with control naming but changing control groups seems eaiser.

and Yairs doesn't depend on any namming convention but more codding changes are involved to change the control groups.

Great discussion thanks Yair and dblk22vball

Anyone else have an opinion on this?

Mark

[Yair]

Any time you place a reference inside FG you have a hidden link.

The link I was refering to was the link between the handling code and the control. If you have such a link and you change the label, the code won't work, but you would have no idea until you execute that code path (and that's assuming it either reports the error or the lack of action is obvious enough to the user).

In my case that link is not hidden, because the reference is statically connected to the control and if you right click the control, you can do Find References and find it. It's true that the code that acts on the control is not directly connected to it, but at least it's obvious that it exists somewhere, because the reference exists, and it won't stop working when you play with the control.

Are you saying you need to have this big ugly bundling of control references on the main block diagram so you are not confused as to what controls get changed?

That's exactly what I'm saying. It's a definite annoyance, but I prefer it, partly because of this:

if one of the control refs that you are bundling refers to a typedef and the typedef is changed during development.

The reference in the stub vi will no longer match and your code will break.

Excellent! I want the code to break. Edit-time alerts are the best kind. If the code breaks as soon as I change something I'm much happier than if it just doesn't work when I run it.

Now, I should point out that you are correct about the issues it has - it does take up way too much space and adding a control retroactively is not the smoothest thing.

I should also point out that I have also gone down the same path you have - I do have places where I've placed the info in the control labels and I parse it at run-time to decide how to act (although in my cases those controls were always in clusters and I at least got the cluster reference statically, so at least THAT can't break). For a large number of controls of the same type with the same code, it's usually a better method. As is often the case, it's a metter of deciding which tradeoffs you want to make.