detect clicked cluster in mouse down event for clusters within multiple stacked clusters

[ChrisReed]

With the help of Ben (see http://forums.ni.com/t5/LabVIEW/Determine-cluster-element-clicked-in-mouse-down-event/td-p/1245770)

I could easily find out what sub-cluster had been clicked on (mouse down event) within the main cluster, by using the Label.Text Property.

However if you have a cluster within a cluster within a cluster then you probably have to use individual mouse down events for each sub-sub cluster.

I just wanted to use one "Main Cluster":Mouse Down event and from that determine which of the sub-sub clusters had been clicked on - is this even remotely possible?

Chris.

[Ben]

---

@Chris Reed wrote:

With the help of Ben (see http://forums.ni.com/t5/LabVIEW/Determine-cluster-element-clicked-in-mouse-down-event/td-p/1245770)

I could easily find out what sub-cluster had been clicked on (mouse down event) within the main cluster, by using the Label.Text Property.

However if you have a cluster within a cluster within a cluster then you probably have to use individual mouse down events for each sub-sub cluster.

I just wanted to use one "Main Cluster":Mouse Down event and from that determine which of the sub-sub clusters had been clicked on - is this even remotely possible?

Chris.

---

Yes but... you will have to pass through 26 Kudos worth of Nuggets to get there (Well maybe you can skip the last 5 or so).

This Nugget by Ton teaches us how to use Dynamic Event Registration. (15 Kudos, must read and understand)

This Nugget by me talks about getting at references inside arbitrary data structures. (11 Kudos, You don't have to read the whole thing, only enough to get at nested objects).

SO use the stuff I wrote about to gather up the references to the clusters. Build them into an array and then use dynamic event registration and what you learned in that thread you linked in your question.

So Possible? Yes!

Easy? YOU tell me.

Ben

[ChrisReed]

Hi Ben,

Well I've always found excuses to avoid using User and Dynamic Events. I know they're very powerful, but they just don't seem so easy to learn as the good old standard Event structure.  However for 26 Kudos worth of Nuggets I suppose it's about time I dove into the deep end and finally learnt how all this works - thanks.

Chris.

[Ben]

---

@Chris Reed wrote:

Hi Ben,

Well I've always found excuses to avoid using User and Dynamic Events. I know they're very powerful, but they just don't seem so easy to learn as the good old standard Event structure.  However for 26 Kudos worth of Nuggets I suppose it's about time I dove into the deep end and finally learnt how all this works - thanks.

Chris.

---

So did I!

But after I got a handle on it... woo hooo!

They can really make a big difference in how we implement our code and keeping it clean. I find them particularly useful for applications that have multiple modes of operation where a set of controls are used in one mode (eg set-up) and another used in another mode (collect). Lets see if I can convince you (or other to take that plunge).

Above is an image of the code that implements the "Analysis" mode of an applcation.

1) At a galnce you can see the events associated with this mode of operation.

2) Event are only registered when they are used so no need to "check the mode" when an event occurs to decide if we should really do "that".

So jump in, try out the posted examples, poke around, and have fun!

Ben

PS the hardest part of dynamic events is find the nodes on the pallette.