Which control in a cluster was responsible for a MouseDown event?

[Vostokki]

Hi,

I've got a cluster with bunch of controls and use an Event case to trigger from a MouseDown event generated by the cluster. How do I figure out which control generated the event?

In a similar problem with a ValueChange event I use oldval and newval to compare which control changed, but I can't do that with MouseDown. 

Any ideas?

Lauri

[Norbert_B · Accepted solution]

Lauri,

the reason that you do not get an information which control within the cluster had been clicked is simple:

The event does not depend on a control within the cluster but on the cluster itself. So if you click on the "blank background" of the cluster, the event will also fire....

The best solution for your request is not to handle a click on the cluster but on the elements within a cluster. The event would look something like this:

The same is btw. also true for value change if you do not want to do the compare stuff....

hope this helps,

Norbert

[Vostokki]

This is what I initially thought, but figured that looking at events for the whole cluster would be more elegant. Since this isn't the case after all I'll go for your solution. In this project this is adequate since I only got a few controls with the need to do MouseDown actions. However I've got tens of controls that generate ValueChanges, so I'm happy with the comparison solution for those, at the time.

Many thanks, Norbert.

Lauri

[SteveChandler]

There is hope.

You have a large cluster and you want a single event case to handle the mouse down for some or all of the controls. You also want to know which control was clicked. The solution is to dynamically register the events.

Edit: I am attaching the vi. The snippet messed with my code by adding the Clust Refnum control. I guess there are some limitations with code snippets that I wasn't aware of.

[DFGray]

As a side note, I usually avoid this sort of construct for the following reasons:

1. If you need to separate out one of the events to add different functionality in the future, it can get difficult, especially if you do your event processing in the event structure itself.
2. The event data you get is the intersection, not union, of the event data sets of the different controls.  This limits what you can do in the future.
3. The last value is a variant, creating even more code to figure out how to convert it, should you need to use it.

In short, you are throwing away information, then trying to recover it.  In some cases, this may be warranted, and it may be worth it, but it does not pass my scalable-modular-reuseable test.  I prefer to have an event for each control and use the event structure as a producer for a consumer task handler.  However, this is my preference.