Event When User Event Becomes Invalid

[Hooovahh]

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

[Intaris]

And adding a "Quit" event won't work?

I would not want this because I have code which relies on the fact that events in an event queue remain valid after destroying the event used to populate it.  Also note that there is NOT neccessarily a 1:1 relationship between a user event (it's quite easy to swap out the user events registered) and an event registration queue, so I'm not sure this request is even properly technically feasible.

[wiebe@CARYA]

I don't see any objections. Sending an event when the user event is destroyed does not need to interfere with anything as it is now. It's just an extra option. The event queue would still remain valid as it is now.

Adding this option does offer opportunities. Like Hooovahh mentioned, if a parallel VI created the event, and it is stopped during development to debug, the VI won't be able to send a quit event. But the user event is closed. Getting an event in all registered event structures sounds like a bonus to me.

[Intaris]

So you mean like an extra notification separate to the event itself?  Kind of like a filter event, but for validity of the underlying user Event?  That I could get behind.

[Intaris]

I could envisage an option to choose to register not only for the user event, but also for associated status changes, similar to how one can choose which event to register for when dynamically for UI elements.  As long as it doesn't change the behaviour of existing code, it's all good.

[wiebe@CARYA]

Just like this (don't think it need to be any more difficult)

before:

  After:

[Intaris]

Yup, that'd get my vote.   I misunderstood the original request.

[wiebe@CARYA]

I hope I got it right.

[Hooovahh]

Thanks wiebe@CARYA for conveying my thoughts for me.  I wish I could edit my idea to add your screenshot because that is exactly what I was thinking.  Yes the quit event is what I use to go through a proper shutdown today.  But if the reference was destroyed for unexpected reasons, I'd still like to ensure my asynchronous loops go through a proper shutdown.  And at the moment I accomplish this with that very slow polling method I mentioned earlier.

[wiebe@CARYA]

A user event can send a data type that can't be a "quit". I often send objects, and I won't like to add a "quit" child to all of them, or add a second user event just to send a quit.

Starting to like this idea more and more.

[AristosQueue (NI)]

> I wish I could edit my idea to add your screenshot because that is exactly what I was thinking.

I asked a moderator to do that edit.

I like the idea.