LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Event When User Event Becomes Invalid

Status: New

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:

before.png

after:

after.png

11 Comments
Proven Zealot

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.

Proven Zealot

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.

Proven Zealot

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.

Proven Zealot

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.

Proven Zealot

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

 

before:

user event before.PNG

  After:

user event after.png

 

Proven Zealot

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

Proven Zealot

I hope I got it rightSmiley Very Happy.

Proven Zealot

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.

Proven Zealot

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.

Proven Zealot

> 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.