More elegant wiring option for properly destroying User Event Refnums

[John_P1]

I find it annoying to have to wire the User Event Refnum around my entire code loop in order to explicitly destroy it upon completion.  It can get pretty ugly with larger loops and creating/destroying multiple user events.

It seems it would be nice to have an Unregister For Events primitive that could return a reference to each of the events that had been registered:

The dropdown might have to include the name of the user event in order to make it clear to the user which event is which, but hopefully the above drawing gets the idea across.

[JackDunaway]

A node like this would (further) break encapsulation and the otherwise loose coupling between Event Refs and Event Registration Refnums. (Why further? Because the Event Data Node exposes the Event Ref.)

In the given example, both the scope and lifetime of both sender and receiver are local to one diagram. In a well-designed interprocess messaging API, neither the access nor lifetimes to these separate refs is necessarily coupled (especially, access to the sender ref). Also, the example connotes a one-to-one relationship between sender/receiver, whereas in reality you may (likely) have multiple listeners for each sender.

Totally not trying to be a stick in the mud... it actually seems like this node would be quite useful and the natural, missing complement for the Register for Events node! It's just that the presence of this node could give rise to anti-patterns, so it's best to not have this ability in the language.

[John_P1]

Hmm... I hadn't really thought of the Event Registration Refnum as a means for encapsulation (I've seen the Event Data Node and I guess had always assumed that there existed other ways to get at the event reference from the registration refnum).  If you're counting on the registration refnum for encapsulation, this change would be undesirable (but then again there is already the event node, so currently you still have the capability of messing with pre-registered events from within a listener thread).

Of course, with the proposed node you wouldn't have to destroy the user events returned by the unregister.  It would be up to the developer (as it is now) to not prematurely destroy an event still being used by another thread.  I do realize that the node might encourage somebody to mistakenly destroy his events in multiple places in the typical case of multiple listeners, but this *should* be a pretty obvious mistake (compared to the current unregister primitive which encourages people to not destroy their events at all!) especially for somebody developing this type of application.  An alternative might be to have a brand new node (separate from Unregister For Events) which has the sole purpose of returning the user events from an event registration refnum (this would explicitly break any encapsulation that you might have had previously).

For what it's worth, my actual use-case which inspired this request does share events across multiple listeners/senders (the above example is probably too simplified) yet I would still make use of this feature if it existed (master thread--itself a listener--stops other listeners before destroying the user events).  However, after thinking it over the slight benefit from this feature probably isn't worth the downsides.

[Intaris]

What I personally would like to see is a NEW Event type or a new "Register for Events" option whish DISALLOWS this kind of access for exactly the same reasons as Jack.

There are nice architectures which can come crashing down terribly because it's IMPOSSIBLE to properly hide the user event refnum, something which precludes using events with classes for example because you can't guarantee privacy.

If there WAS a "Private" option for registering for events then I'd be OK with this option.  It's a functionality I've wished I had in the past, but I'd strongly disagree with this without the private option.

See my Idea HERE.

[SteenSchmidt]

You could just protect the event refnum in private functions. Both the event creation and use of it.

/Steen

[Intaris]

Steen, you're wrong sorry, you can't.  You have comletely missed the point.

Once you connect an event as pre-registered it will ALWAYS show the naked refnum in the event structure when fired.  Regardless of whether I have private functions for otherwise dealing with the refnum (which I do regularly of course).  I DO need to expose the registered event refnum otherwise the event is kind of useless.  Exposing the Registered Event AUTOMATICALLY leads to an exposure of the underlying User Event once fired in the event structure.  Bang, encapsulation is gone.

Unless someone can show me how to use the event structure in such a way as to circumvent this problem.......

[SteenSchmidt]

Shane, ok, if you also expose the event structure handling the event, for a user to program some event handling code in - then the event refnum is out of course.

I was thinking about the case where you only expose some public function that inside it has an event structure that you've preprogrammed for some action. Like "drop this VI into your code and have it wait for and act upon a pre-determined event". I agree this limits the flexibility of your code to the functionality you can dream up and which you are prepared to implement up front, but on the other hand you've encapsulated your functionality and protected your private events while retaining event-driven functionality.

If your user has access to the registered event, then yes, everything's open. There should maybe be some way of marking an event as private, thus hiding the event refnum data node from inside the event structure in those cases? Could be valuable...

I've kudoed your idea, but I don't know how much it would take to bring it further out in the light from a couple of years back. I feel LabVIEW use has risen in complexity since then, so your idea could probably gather more followers today than it did back then?

Cheers,

Steen

[Intaris]

Steen,

encapsulating the event structure, while it would indeed guarantee safety of encapsulation, really degared the usefulness of User Events so far that I would actually say it negates any reason for using them int he first place.

The "Private" option is something I feel simply belongs in LV.  Exposing pre-registered refnums (when not desired) is terrible.

[SteenSchmidt]

Shane,

I don't think encapsulating the event structure is a solution to all our use cases where we need to protect the event refnum, not even to that many of them. I'm just saying that that was what I meant with my original comment ("You could just protect the event refnum in private functions. Both the creation and use of it").

I agree it's a poor substitute though, so let's vote for a private event refnum possibility in LabVIEW .

/Steen