Support more complex clusters of event registration refnums

[Intaris]

Currently, we have the option to cluster event registration refnums when working with the Event structure to allow for some modicum of organisation.

A co-worker recently tried to wire up a cluster of clusters of event registration refnums and was surprised that it didn't work.  I thought he'd made a mistake but to my dismay I could not get it working.  It seems that there's a one-cluster rule when working with event registration refnums with the event structure.

I think everyone would agree that more hierarchical organisation of User Events is a good thing so my proposal is that far more complex clusters be supported by the event structure, allowing us for more hierarchical structure of events.

My example does not include a name for the topmost cluster of the lower example - obviously naming the clusters / events would be far more useful when using events.

[X.]

Not a comment but a question: can you use a Bundle By Name in your examples above (you seem to be hinting at something like that)?

[AristosQueue (NI)]

X: also broken:

[Mythilt]

Don't have LabVIEW in front of me so don't know if this works, but what about using an array of user event references instead of a cluster?

Or are Event References considered too different to properly array due to the internal typedef aspect of them?

[X.]

@Mythilt: An array of Events of different type cannot be built.

@AQ: when asking my question about bundle by name, I did not think about what you are illustrating, but rather thought that there was a difference in the Event Structure between how the user events are called if they come through a bundle without name and one with name:

In the meantime, I verified that there is no difference.

With an "anonymous" bundle, here is how the Event Structure looks like:

With a bundle by name:

there is absolutely no difference.

This digression aside, it is unclear to me what benefits bundling clusters rather than having a larger bundle would really provide. I understand that it is an unexpected limitation, but it seems one that we can leave with (but it would be nice to document it somewhere).

[Intaris]

What is the benefit? Ifyou have several sources of event registration refnums which are already clustered you currently need to unbundle and rebundle ALL of them. This should not be required.  Plus it gives us multilevel structure within the event structure config window.

[X.]

I think the last point is the killer. Too much work 🙂

Note that I am not saying hierarchy/flexibility to organize things wouldn't be welcome in the Event Structure (and elsewhere).

[Intaris]

The hierarchy is already there, it just needs to expand beyond a single level. I dont see the work you refer to......

[Intaris]

Aargh, ran out of time editing.  The intended scope of this idea relates purely to the structure of the "Event Sources" tree within the Event Structure configuration window.

Take this image as an example:

The "Event Sources" tree on the left can, for normal static events, contain arbitrary depth due to Tabs and clusters.

The Dynamic events however are limited to the name of the registration refnum and the individual events contained within.  Yeah, we may have multiple registration refnums (clustered in a shallow cluster) but I don't see where the problem lies expanding this to allow for a deeper hierarchy if we try to wire clustered registration refnums as outlined at the beginning of this thread.  The tree is already there, it can already handle much deeper hierarchies, I don't see any major technical barrier to be honest.

[Intaris]

When you get to 200+ events being handled by a single Event structure, organisation of events into cohesive groups suddenly becomes a very worthwhile pursuit.

[X.]

I agree. I guess I am not a big fan of multilevel tree structures...