How to programmaticaly list front panel control references into a cluster

[FabriceMTL]

Hi y'all.

I am actually using LV 2011 and when we create an application with a lot of front pannel control, it's a pain to go and create individually the reference of each one (and if you add one you have to remenber to create the reference and go and update the code etc... it's quite a pain for such a trivial task).

I can scan the front panel a detect each control but i don't know how to programmaticaly create a cluster from it... Below are my attempt so far: 

cluster : This one is not done programmaticaly since i have to specify the size of the cluster and also I no longer have the reference label as with output cluster.

array of cluster : Well it's an array not really what i want but once i extract the cluster from it i end up with almost the same situation as with cluster  expect here I don't have to specify the size of the cluster.

The result I want must look like output cluster but where I won't have to create manually the reference for each control.

[altenbach]

I am just wondering why you need all these references?

Maybe there are better ways to achive whatever you are trying to do.

In this particular case, a 2D array of booleans would be more reasonable and would keep the diagram orders of magnitude simpler.

If you also want the labels, you could create a cluster of a string and a boolean, then create a 2D array of such clusters.

[tst]

In general I agree with altenbach - a cluster of references is rarely a good idea. However, there are some cases where it can be useful and some years back I posted an RCF plugin which does this - https://decibel.ni.com/content/docs/DOC-5813

Since you probably don't have or want the RCF installed, you will need to adapt the plugin to be called from Quick Drop.

[FabriceMTL]

Hi altenbach!

The Booleans are just for the example purpose. I need the reference because it's for a touchscreen application interface and I want to keep track/update the value/property of different controls on the front panel on the main Vi on different subVis  (can be any type of controls, indicators,graph, enums,listbox etc.).

Arrays are tedious to work with because I think it will be hard to identify and just extract the control i need to take action on (example in subVi initialise I want to disable and gray out bunch of control and and then take the value of different controls to do initialisation task, at the end update indicators with result - when the user select another task, then in another subVi I'll do different operation related to the values on the controls of the FP on the main Vi and then update the graph indicator- etc) ...I don't if it's clear enough like that...

I like the ability to bundle/unbundle by name wwith cluster which I can't do with an array but don't like having to build manually the array off references.

[FabriceMTL]

Hi tst

-Why is a cluster of references a bad idea? Is there a better way if you want to update/get value from UI in different subVis?

-The plugin you posted appear to do exactly what I want. In order for me to test it (reminder I use LV 2011), I just have to install the as per your instruction (unzip the folder into the <LabVIEW>\resource\JKI\RCF\Plugins), restart LV and create a shortcut for it in Quick Drop? Not having and not knowing what RCF, where should I install it?

[tst]

---

@FabriceToe wrote:

-Why is a cluster of references a bad idea? Is there a better way if you want to update/get value from UI in different subVis?

---

This is a very big topic and you would have to go read up on software architectures design, but the basic idea is this:

1. Tying your UI directly to your logic is problematic. It's very convenient in LV, but it often means you don't have enough modularization, etc.
2. Manipulating the same UI directly from multiple places can be an issue in that it's very easy to start having race conditions and not being aware of them.

I don't have an answer for you about a better way, both because that's a big topic and because it depends on both the specific project (size, type, etc.) and the people doing it. One common practice is to separate different modules completely and use different mechanisms to pass messages between them.

As for the plugin, you will not be able to use it with the RCF installed and you will need to modify it to work with QD. If you know how to write QD plugins, it should be easy to just open the code (ignoring the missing VIs), look at it and convert it. If not, you will need to learn about how QD works anyway before you can do this.

There was a tool posted on LAVA a few months back for doing automated adaptations of RCF plugins to QD plugins, but I never tried it.

[Florian.Ludwig]

Hi,

you can basically do what you want with arrays. I'd keep an array of the names of the controls together with the array of references.

That way you can search the name array for a control and index it in the ref array.

Since that can be used to sidestep LabVIEW's dataflow paradigm (and create race conditions, as metioned by tst) you'll have to start using best practices from other programming languages too.

I'd suggest using unique structured names for your controls for example. Maybe something like this: subvi_control_datatype.

[billko]

---

@tst wrote:

---

@FabriceToe wrote:

-Why is a cluster of references a bad idea? Is there a better way if you want to update/get value from UI in different subVis?

---

This is a very big topic and you would have to go read up on software architectures design, but the basic idea is this:

1. Tying your UI directly to your logic is problematic. It's very convenient in LV, but it often means you don't have enough modularization, etc.
2. Manipulating the same UI directly from multiple places can be an issue in that it's very easy to start having race conditions and not being aware of them.

I don't have an answer for you about a better way, both because that's a big topic and because it depends on both the specific project (size, type, etc.) and the people doing it. One common practice is to separate different modules completely and use different mechanisms to pass messages between them.

As for the plugin, you will not be able to use it with the RCF installed and you will need to modify it to work with QD. If you know how to write QD plugins, it should be easy to just open the code (ignoring the missing VIs), look at it and convert it. If not, you will need to learn about how QD works anyway before you can do this.

There was a tool posted on LAVA a few months back for doing automated adaptations of RCF plugins to QD plugins, but I never tried it.

---

I use a typedef'd cluster of FP object refs to set properties inside subVIs, like a front panel init, for instance.  I may never use it anywhere else, but to me it's worth it just for that one thing.  Then if I need to add a control or indicator later, I update the cluster and I can just go right into the init subVI and init that control, too.

I don't know about the race condition thing, though.  It seems to me that you really shouldn't be updating front panel objects from more than one place anyway (race condition avoided).  If I have a control/indicator being updated from more than one place, it means that I don't care if they step all over each other (for example, a boolean that represents hard drive activity from multiple drives).

I guess you are saying that it could lead to lazy, sloppy programming, though?

[Bob_Schor]

Sorry I'm so late to this discussion.  While I definitely agree with the comments about "Why are you doing this?", and about the dangers of using Front Panel Controls and Indicators as "variables" that you use to pass data back and forth between sub-VIs, the first thing that struck me was your array of Booleans on your Front Panel that you were treating as 20 different Booleans!  What a waste!  I'm attaching a Boolean Array control that I just cooked up that looks like this:

I made this by creating a 2D array on my Front Panel and dropping in the Boolean Control you see here.  I dragged it to a 5x4 size, then clicked the control in the lower right to instantiate all of them.

To get the numbers, I created a TypeDef, opened the Type Def, and went into Edit mode.  The numbers are actually a Text Decoration, spaced to fit.  I had to adjust the size of the Boolean control slightly to line things up (this probably won't scale well), and make the background of the Decoration transparent.  Once I had it positioned in the right place, I did a Select All and used the Reorder button to Group the array and decoration together.

One minor caveat (besides this control being somewhat "inflexible" in size) is that the buttons are labelled 1 to 20 (for easy of the User), but are addressed as elements in a 4 by 5 matrix, i.e. 0,0 = 1, 0,1 = 2, 2,0 = 11, and 3,4 = 20.  However, it should be pretty trivial to write a pair of LabVIEW functions that translate Button Number (1 .. 20) to Button 2D Index, and back again.

Bob Schor

[FabriceMTL]

Hi Bob_Schor,

---

...the first thing that struck me was your array of Boolean on your Front Panel that you were treating as 20 different Boolean!  What a waste!  I'm attaching a Boolean Array control...

---

As I said earlier having 20 Boolean control was just my lazy way of creating a bunch of control for the example to indicate that i need a way to programmaticaly list they reference. In my real project the controls are not just Boolean, it can be of any type of data  from numeric to string, to graph and listbox etc... Don't mind the type of the controls i used in this example and also in the real project it's not just 20; I didn't count them yet but i'm sure it's close if not more than 100 controls ( again it can be indicator-control-graph-table-listbox etc of any type numeric, Boolean, waveform, string etc.).

Cheers!

Fabrice