Separate Events for Controls in a Cluster

[GregFreeman]

I have always had a single event case for a cluster's value change event and then determined, within that single event case, which control changed. Is there anything inherently wrong with having a separate event case for controls within a cluster if needed, or do you run the risk of locking things up because the cluster terminal can only be put withiin a single event case?

[altenbach]

You don't need the cluster terminal. Just read the new value from the event data node.

(Of course I am not quite sure what would happen if you would have an event for a value change of the cluster AND an a value changed event for one of the cluster elements in two different event cases. It seems allowed, but I am not shure what would happen first.)

[GregFreeman]

---

@altenbach wrote:

You don't need the cluster terminal. Just read the new value from the event data node.

(Of course I am not quite sure what would happen if you would have an event for a value change of the cluster AND an a value changed event for one of the cluster elements in two different event cases. It seems allowed, but I am not shure what would happen first.)

---

Sorry, I should have been more clear. I would remove the value change event for the cluster, and have a separate event for each of the controls which need one. I am worried about that whole the-terminal-should-be-in-its-respective-event-case caveat which is impossible if you have a single cluster terminal but a separate event case for more than one control within it.

[crossrulz]

I see nothing inherently wrong with that as long as you are just using that one value from the cluster.  As Christian stated, be sure to use the "New Value" from the event case.

If you need a bunch of values from the cluster for this one case, then I say you are asking for trouble as you will need the terminal or a local variable.  And at that point, you might as well go back to the full cluster value change.

[GregFreeman]

Sounds good; it's not so much the "architecture" of doing this thats the issue. It's that you can cause weird locking if you do not put a boolean inside its respective value change case, for instance. I want to be sure I'm not going to have weird panel behaviors by doing this.

[altenbach]

Using local variables would seem problematic. because if several elements are changed concurrently (e.g. by "right-click, reset to defaults" at run time), the local variable might reflect other changes that might not have been handled yet. This may or may not be OK, depending on the overall architecture.

I would probably keep the cluster data also in a shift register and use "bundle by name" to merge the new data from the event data node in each event case.

[GregFreeman]

Yup, the SR/bundle by name is how I have it implemented. Thanks guys.

[mikeporter]

This really isn't a case where you can say one approach is universally better than the other. I have done both depending upon what the cluster data looks like, the actions the data changes will trigger, and the desired functionality.

On the one hand if I have a cluster of different data types that result in different kinds of operations I would tend to handle them separately -- though that isn't guaranteed.

But on the other hand, if I have a cluster of booleans or numerics that all do the same type of thing, but with a different target for the action, I would tend to handle them together -- but again it isn't guaranteed.

The best solution is the one you get when you let the application tell you what it needs.

Mike...