Allow Destroy User Events and Unregister for Events to Accept Cluster of Refnums Input

[jgcode]

At the moment you can Register for Events using a Cluster of Refnums.

But you cannot Destroy User Events or Unregister for Events in this way.

This approach allows for you to scale your application without the need to change the code that handles Registering Events.

It would be very convenient to be able to close references in this way (using a Cluster of Refnums) too, as per my illustration below:

[JackDunaway]

Yes! I have more to say about clustering and arraying references, but I can mark this one off the backlog. Good ask, Jonathan!

[jgcode]

Thanks Jack.

I am sure you do 🙂

Keep those good ideas coming!

[JackDunaway]

OK, in reference to clustering and arraying references, I'm going to do a lot of thinking out loud:

In general, any destroy/close/unregister method for event and control references should be polymorphic for a single ref (definitely), an array of references (definitely), and as this Idea suggests, a cluster of those references (some might argue this one...).

Arraying:

Currently, the Close Reference primitive will accept a single control ref or an array of control references, good. "Unregister For Events" and "Destroy User Event" only accept single refs, but not an array of references, bad. This seems like a hole in the language (but perhaps it's not allowed for good reason? I can't think of one.). Either way, an auto-indexed not-so-vestigial-because-of-the-hole-in-the-language FOR loop is a valid workaround and still allows for scalability. One problem: you can't array dynamic event registration refnums of different types, and even if you create an array of these refnums that are the same type, you cannot wire it into the Dynamic Event Terminal on the Event Handler Structure.

Clustering:

Well, what if the cluster contains a piece of data that's not a reference that can be handled by the close/unregister/destroy node? Does it break the wire, or does it perform the action on each member that has a type the method can be performed on? Wiring clusters into methods expecting a "for each" action seems iffy... better left to an array. I think the only reason we currently cluster messaging refnums together is because arraying is not allowed (note: arraying messaging refnums is not allowed, but you can array control refnums by upcasting to the common base class).

Synthesizing the two ideas:

Would there be a way to generically upcast messaging refnums to be a more generic "base" refnum (Queue, Notifier, User Event...) so that the refnums could be arrayed? Then you could definitely coherently wire several types of messaging references into unregister/destroy primitives.

I have Kudoed this Idea not because I specifically want it to be implemented, but because I want to drum up some conversation on a topic where, like JG, I have run into roadblocks.

[jgcode]

Great discussion Jack.

Thanks for the pseudo support (I think!) 😉

As you mentioned, Arrays must be of the same datatype

Therefore, another logical container to use is with Event Refnums is a Cluster.

However, using a Cluster is even more logical given the interaction that already exists with the Event Structure and how Dynamic User Events are be registered for, with each appearing by name in the Add Event Dialog.

With this is mind, I am not sure how an Array would be handled given that each name in an Array would be the same etc... (do you have any thoughts on that)?

But I can definitely see the advantages or convenience that this may have.

Although my Use Case is using a Cluster as a container i.e I register a  Cluster of Refnum Events with the JKI State Machine, (as per Justin's demo for State Machine vs State Machine at NI Week) to communicate to/from the GUI/process.

Additionally I think destroying a Cluster of Event Refnums should be supported as the creation of Registering for Events using a Cluster of Event Refnums is already implemented. But I would not expect a Cluster containing data other than Event Refnums to be allowed to be wired into the Destroy User Event primitive, just as is currently the case for Registering for Events. 

[JackDunaway]

---

@JackDunaway wrote:

Well, what if the cluster contains a piece of data that's not a reference that can be handled by the close/unregister/destroy node? Does it break the wire, or does it perform the action on each member that has a type the method can be performed on?

---

Soon after I wrote this I realized the answer - the wire breaks. At first I could not think of a precedent where an operator performs "for each" element on a cluster, but this is crazy - there are dozens. I'm fully on board with you.

Forget my idea about upcasting Control or User Event Refs in order to avoid clustering by arraying... clustering and arraying have two distinct purposes, and it's crazytalk to try to interchange the two.

Here's a diagram of how I think all close/destroy/unregister nodes should work - there should be no broken wires in the Proposed Method. Note the Proposed Method is scalable, robust against any datatype changes on the left side of the diagram.

[GregFreeman]

This seems to have been completed but is still marked as new. I haven't checked destroy user event, but the unregister for events primative now accepts a cluster in 2013. Good news!

[Brandon.Baxter]

I know this is an old post but I just have to ask what is this:I have wanted something like that for a long time

[fabric]

---

@Brandon.Baxter wrote:

... what is this ...

---

It is called "Coerce to Type": http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213...

[TomOrr0W]

For GregFreeman's comment about this being completed, unregister does indeed support clusters (and apparently has since LabVIEW 2013).

However, as of LabVIEW 2018, Destroy User Event does not support clusters (nor does it support arrays).  Therefore, the idea is not yet completed.

[tobiy]

Destroy User Event has still no Support at least up to LV 2019.

Is there at least some kind of workaround available, e.g. based on casting the Cluster to some kind of array which can be indexed in a for-loop and destroy the events individually ??

Unclustering all the events and destroying them separately makes very messy block diagrams.