Don't expose the Refnum to a pre-registered User Event within the Event Structure

[Intaris]

I like using User Events.

I find them intuitive for (certain) communication between code modules.

One thing bugs me though.  If I decide to keep the Event private to a certain module and only release a pre-registered User Event (registered for each listener) careless code can bring the entire communication to a halt.  The bare User Event refnum (pre-registration if you wish) is exposed within the Event Structure.  I have yet to understand wha this is but whatever the reason, it essentially means that it's a serious problem for 1 to n communication.  If one of the n listeners decides to destroy the user event, communication to ALL listeners is destroyed.

I wish we could set the User Event refnum to being private so that it would NOT be exposed within the Event Structure.

Shane.

[AristosQueue (NI)]

I checked in with one of the experts about the Event Structure. I asked why the refnum is exposed. Here's the feedback:

Why is it exposed?  Because you might need it.   It might be legitimate in your app to destroy the event after it's handled, or, more commonly, you might re-fire the event with different data.

The other reason is orthogonality:  ALL events, no matter the source or type, present the refnum of the object for which they were fired.

I can see why in this particular case, where the user has intentionally designed a system where the clients of user events are presented an API intended to be opaque and separate from their registration and firing, that the user would want to hide the event.  I'm not sure how common this scenario is.

 The simple answer is "Don't do that."  If you want to hide the user event just to prevent accidental misusage, I'd suggest providing a template VI to be used to make user event handlers in which the user event has been pre-hidden in the event data node.

The developer did note that it might be possible to add an option to the Create User Event that would make the refnum private so that it doesn't show up. That would allow you to code the solution you're looking for.  If this idea were to get enough kudos to be acted upon, that would likely be how it would be implemented, unless you have another proposal. It doesn't sound like just removing the refnum would be implemented.

[Intaris]

I realise that changing current behaviour would be bad, but having the option when registering for the Event to keep it private would be great.

[JackDunaway]

AQ, thanks for taking the time for such a good response.

I may be on the other side of the fence as Shane here... I would like one extra way to expose the "hidden" user event refs contained within the dynamic event ref wire. The "Register for Events" acts as a writer for all the underlying user events, but I would like another node that acts as a reader for those events. (Think of property nodes, right clicking on them, and "Change to Read"... doing so to the "Register for Events" node would allow you to get the wrapped references).

Some places where this would be handy:

1. When you're dynamically unregistering or swapping a User Event, and you want to "set aside" the original user event for re-registration later. This currently must be done by maintaining a reference elsewhere other than the dynamic events wire.

2.  When dropping the Unregister for Events node, often you'll want to destroy the User Events. Again, to do so, you can't get those user event refs from the dynamic event ref wire, you must maintain them separately.

Of all the places to expose the User Event ref, as data in the Event Structure is the least handy to me. If you consider the dynamic event ref wire a "conduit", I would like read access to the user event reference wires within.

[Intaris]

Would a viable option to this problem (and it is a real problem when trying to design a re-usable piece of code running asynchronously using events) to have an option to prevent destroying the reference?  This would retain the ability to re-fire without impacting the robustness of a one-to-many API using events.

[Intaris]

I just want to re-iterate my last point.

Can we have an option to create a restricted user event (where the refnum is not destroyed) via a boolean input on the "Create user event" node?

Such events would be of a different data type than normal User events, but would remain compatible with the event structure and so on.  The only difference would be that the actual refnum itself would not be visible.....

[JackDunaway]

---

@JackDunaway wrote:

I may be on the other side of the fence as Shane here...

---

Two and a half years later... I'm on the same side of the fence as Shane now. The points I mentioned above represent anti-patterns I was using at the time, and have since found much greater success wrapping messengers inside a class with a well-defined API. So... Kudos!