Best way to share/update front panel buttons

[FabriceMTL]

Hi y'all!

I'm quite a beginner in LabVIEW (2 years of experience: 1.5 year academic and mentoring a FRC team and .5 professionnaly as a fresh graduate in a startup).

We develop an application using LabVIEW that is aimed to be touchscreen friendly and thus we have a lot of front pannel boutton we have deal with. In order  to make the current code more readible and easily scalabe, I'll like to know if there is an efficient way of treating front pannel controls.

To illustrate it, let say i have this UI:

The actual way we propagte those controls is by building a cluster of the reference of all those controls (that's where i wish we had LabVIEW 2012 -_- ) an then unbundle the one we need in the appropriate section of code (thats means a lot of wires everywhere...)

So are there better ways to acheive the same goal ?

Thanks! 

[Ben · Accepted solution]

I spoke of a GUI Controller in this thread. That may give you an idea.

Ben

[aputman]

Why do you need to store the references?  Are you going to enable/disable the buttons? 

If you only need to know when a button was clicked, use an Event Structure and create a Value Changed event for the button. 

[James.M]

Clustering can be your friend here. I could see all the controls on your Front Panel bundling down to 3-4 clusters. Those arrow keys could be one, the ok/cancel buttons another, the buttons on the left as a "menu control" cluster, and the other tab as one big cluster of buttons as well.

[FabriceMTL]

Thanks Ben and James.Morriƽ for your replies.

So in other word building a cluster is the way to go here.

How about scalability? If later on we add another tab with a bunch of controls won't I have to make modification on the code later on? i.e. off course I will have to add the new references to the cluster but even if it's a type def, won't my ouput cluster be broken? and thus require  me to go delete and create a new indicator on every subVI where the cluster is used?

[FabriceMTL]

Hi aputman,

This example is not very representative but yes I'll need to enable/disable read/write values etc of the buttons (can be booleans, tables, indicators, controls, etc.) that's why i need the references.

[James.M · Accepted solution]

This is where type-defined clusters come in. Right click your cluster and Make Type Def. This will create a ctrl file that stores the data type of that cluster. When you make subVIs, arrays, whatever of this cluster after you make it type-def, you only need to update the single type-def control for it to update everywhere. When you first make it, make sure to go and replace any clusters you already have because it doesn't automatically update matching clusters with the type-def.

This is all helpful if you do really need to bring a cluster of references with you everywhere. Why are you creating this cluster of references?

I see your post above about needing to enable/disable controls. An alternative could be just to use the VI ref and pull all controls when needed.

If you're going to just enable/disable and don't need the specific datatypes, could you create arrays of references instead of clusters? You can use a For loop and a property node to enable/disable an entire array of control refs. The arrays could be built based on your application needs.

[Ben]

Hi James,

The array approached is valid if all we want to do is disable/enable all controls. The elegence of the cluster approach allows the reference to be of the type of the control itself so that when we register a dynamic event against a control in a sub-VI, we have the actual type of the data insead of generic refs.

Ben

[FabriceMTL]

Ah! Actually making the cluster typeDef was the solution I need for scalability

In my previous attempt my mistake was in the sequence I build the cluster :

1-Bundle the reference and create an indicator

2-Copy the indicator and change it to control

3-Replace bundle with bundle by name and connect the control cluster

4-Make the control cluster to TypeDef  (and that's why my output cluster wasn't typeDef)

About the use of references, some of the controls (not illustrated in the example) are indicators, controls and graphs too. So it's not enable/disable only but also read/write values etc.

[Sam_Sharp · Accepted solution]

Another neat trick when you have lots of buttons and you don't want to create an event case for every button is to have a 'catch-all' value change case in an event structure.

There are quite a lot of different techniques in this VI snippet which are useful for dealing with lots of buttons:

1) You can statically register for the value change event of multiple controls - as shown above

or

2) You can use cluster to array to get an array of references which you can dynamically register events for (if you're passing the cluster around though, you should use a type-definition)

3) The value change event returns the control reference of the control that was clicked - so you can use this to get the label of the button that was pressed and then based on that perform different actions (e.g. enqueue a command to another loop)