Method of Bundling Controls Independent of Front Panel Location

[PhillipAC]

Is there a way of "Bundling" controls independently of their location on the front panel? From most example I have seen combining controls into groups that one could say create an event after is done with clusters. However it seems like clusters are also tied to the location of the control on the front page. Ideally I would like a way where I could place the controls (like buttons) anywhere on the screen and have them all tied to one event that could execute some command based on which one was pressed. I realize that I could just have each button attached to a separate event but that seems like it could create an event structure with a huge amount of sub-diagrams with a lot of repeated code. It would be nicer to have a way to pair controls to a commands (like a string) and just tell it when one of the buttons in this "bundle" is pressed "send" the respective command regardless of where the button is located on the front end. 

[cbutcher]

There are two parts to your question:

1. Trigger shared code via an event structure for multiple controls
2. Send a command that is defined by the control clicked.

Part 1 can be handled by adding multiple Events to a single case:

Here neither event is tied to a control, but you could certainly do that.

Part 2 can be handled by using the Label, Caption (perhaps) or perhaps Description to define the command. A vague example is below:

A backsaved copy (for 2015) is attached.

[RavensFan]

You can add multiple controls to a single event case.

Then you can use the terminals on the inside of that case to get a reference to the control that fired the event.

[Artem.SPb]

You can combine some events into one event case. And find pressed button by different ways.

[Artem.SPb]

cbutcher and RavensFan were faster than me

[Mark_Yedinak]

Be careful how much code you put into any case in an event structure. You should not be doing anything that requires any significant amount of processing. Event handling should be very quick so you can process the next event in a timely manner. If you have lots of processing in your event cases your code will appear to be very unresponsive because your are doing some heavy processing while other events are getting queued up. The processing should be done in a separate task. Look at producer/consumer or message handler architectures.

[PhillipAC]

Thanks to everyone for the answers so far. As far as code in the events, the idea here would be that the event just queues up the "command" based on which button is pressed. I guess my disappointment with the solutions suggests as they require adding the button values to the event case each time a new button is created. Ideally it would be nice to have group of sorts that could have one "sub-diagram" that just says "find the button in this group that was interacted with and queue the associated command". This way we can define the buttons and their associated commands in one location and the event would just naturally grow with this group of buttons without us having to add to the cases. I've been able to accomplish this with clusters; however, since clusters are tightly coupled to the front end that would not work well for us.  

[RavensFan]

You could create clusters with controls scattered all over the place. I wouldn't do it my self.

Make a large cluster using the classic palette.  Drop all the controls you want in there and arrange as you see fit.  Any controls you don't want in that cluster, but are in the neighborhood, drop them outside the cluster and use the cursor keys to position where you want.

You can then color the border of the cluster as transparent to make it look like it is even a cluster.  Make sure the Z order of the cluster is set to move it all the way to the back so the controls that aren't in the cluster are not hidden by it.

I would work for a user of the program, but is very unfriendly to the programmer.

I would just use the method that all of us described before now with separate controls defined in the same event case.

[mcduff · Accepted solution]

Would something like this work? You could always get the references in a subVI.

mcduff

[PhillipAC]

To be fair all these options seem to be unfriendly to the programmer. I fully agree a large cluster that is just set to be invisible is a horrible idea. It seems fairly crazy that there is not a way to decuple the front end from the back end. So far I prefer the last example given although it still is less than ideal. Thank you to everyone who gave examples.