Jump to content

When are events queued/registered?


Recommended Posts

In looking through the CLD-R prep material, I ran across one example problem that made me realize I didn't quite understand how Events are registered/queued/whatever.

 

See the attached image.

 

post-12368-0-14727600-1448918190.png

 

In it, Value1 gets set to a certain value by means of a Val(Sgnl) property node.post-12368-0-14727600-1448918190.png

 

When executing this code, Value 2 will be set to the same value as the constant set to Value 1 (in other words, it gets set to 10).

 

What I'm not understanding is the event queue mechanic. Before reviewing this and running the code, I would have assumed that the Val(sgnl) write event would have been discarded since there were no Event Queues set up at the time of the signaling event. Clearly though, the event structure Value Change event triggers once the dataflow gets to that point in the program.

 

Do all events simply start stacking up in an event queue somewhere from the beginning of program execution? Is there an intelligent manager that only stacks up events for potential queues that may or may not happen later in the code?

 

Similarly, if I duplicate the Event queue in that While loop (and change the Value 2 to a new variable, call it Value 3), then both queues get executed. Is there a separate event queue/stack/whatever for each event structure?

 

Thanks for the help. If there is already a good thread on this please link me- I did some searching and didn't see anything.

  • Like 1
Link to post
Share on other sites

When it comes to dynamically registered events, you are correct.  If I generate a bunch of user events, then register for them, my event structure won't see the previously generated events, because it wasn't registered for them, when they were generated.  Only events generated after registering will be seen and handled.  It's like enqueueing elements, when the queue hasn't been initialized yet.

 

But when it comes to static events, LabVIEW knows what it needs to register for.  While I can't say for certain, I always assumed it registered for these static events, when the VI is started, before any code is executed.  In actuality it might be registering for the events before the VI is even ran, but for this discussion it doesn't really matter.  All that matters is static events are registered before code execution, presumably because LabVIEW can know what it needs to register for, and does it for you.  When it comes to dynamic events you have more control over when to register and unregister so that isn't the case.

 

As for your other question.  Each event structure does get it's own queue to stack events onto.  If you have two event structures, and they both register for the same user event (remember both register, not just register once and give that to each) then firing that one user event will be handled in both cases separately.  This can be useful for a 1-N type of communication where one action is handled in N places, like a Quit event.

 

When it comes to two event structures sharing the same static event, I think things are inconsistently handled.  By that I mean if you have two event structures, handling the same boolean Value Change control, some times they both get the event, sometimes the first structure will get it and the other won't, or the sometimes the second structure gets it but not the first.  Basically avoid this situation in all LabVIEW code.  Because of this, and for code simplification, it is highly recommended that you only have one event structure for each VI, but that alone isn't bad for your code.

 

EDIT: Still avoid the described situation, but as Jack said, I was confused about when this situation would happen.

Link to post
Share on other sites

That makes perfect sense. Thanks for the help! I've been using event structures for a while now and these situations haven't come up too often- certainly no multiple event case applications. It just hit me that I didn't really *understand* them until I saw that question come up in the CLD-R prep material.

Link to post
Share on other sites

Note that this also means that if you place an event structure inside some other structure - for example, in a case structure - then events will stack up in the queue for that event structure even if there's no possibility of it running. Coupled with the option to lock the front panel until event processing completes, this can (and often does - see the NI forums) cause a lot of confusion, because the user clicks a button and the front panel freezes but since the event never processes, the front panel never gets freed.

Link to post
Share on other sites

Coupled with the option to lock the front panel until event processing completes, this can (and often does - see the NI forums) cause a lot of confusion, because the user clicks a button and the front panel freezes but since the event never processes, the front panel never gets freed.

Yeah I suspect new users think of an event structure as a type of interrupt, or goto function, and when dataflow is the name of the game, that just isn't the case.

Link to post
Share on other sites

Note that this also means that if you place an event structure inside some other structure - for example, in a case structure - then events will stack up in the queue for that event structure even if there's no possibility of it running. Coupled with the option to lock the front panel until event processing completes, this can (and often does - see the NI forums) cause a lot of confusion, because the user clicks a button and the front panel freezes but since the event never processes, the front panel never gets freed.

 

Interesting- so does the "lock during processing" start when the event is triggered, or when the event case dequeues the event from its stack?

Link to post
Share on other sites

I never really messed with this feature much, so I had to write some test code to see.  It appears the locking of the FP occurs on static events when the event occurs, not when it is dequeued.  Same goes for dynamic control references, if the register has the "Lock Panel Until Handler Completes" by right clicking the register for events.  As for user events, it appears this isn't an option because user events don't involve UI controls.

  • Like 1
Link to post
Share on other sites

I never really messed with this feature much, so I had to write some test code to see.  It appears the locking of the FP occurs on static events when the event occurs, not when it is dequeued.  Same goes for dynamic control references, if the register has the "Lock Panel Until Handler Completes" by right clicking the register for events.  As for user events, it appears this isn't an option because user events don't involve UI controls.

 

Awesome, thanks for checking into that :)

Link to post
Share on other sites

When it comes to two event structures sharing the same static event, I think things are inconsistently handled.  By that I mean if you have two event structures, handling the same boolean Value Change control, some times they both get the event, sometimes the first structure will get it and the other won't, or the sometimes the second structure gets it but not the first.  Basically avoid this situation in all LabVIEW code.

 

This one bit is not quite correct. You're thinking about multiple Event Handler Structures binding to a shared queue created by a single Register For Events Node. That's the scenario that produces undefined behavior. (Not just unpredictable behavior; truly undefined behavior)

 

Multiple Event Handler Structures bound to a "Statically-Registered Event" are OK, but as hooovahh suggests, not usually recommended.

 

---

 

"Statically-Registered Event" -- contrasted with "Dynamically-Registered Event" -- is just a silly terminology for "magic wires that you don't see that you just 'know' must exist".

 

The original post is an excellent case study for the mental leap required to learn/believe/trust/understand Static Event Registration.

 

For some reason, in LV world it's taught that Static Event Registration is "easier" than the "advanced" topic of Dynamic Event Registration. Maybe if Dynamic Event Registration were taught like this -- it's wires you see, in the code you wrote, that code in front of you on the block diagram; that's what happens and why it happens. And lifetimes of both the event sources and event sinks -- yeah, that's kinda just wires too -- the wires you see in front of you, on the code you wrote. Understand this, and then the concept of "Static Event Registration" might help you by replacing a little syntax with some accepted, implicit convention.

 

Said another way -- Dynamic Event Registration is syntax where the mental model maps to the visual source model, whereas Static Event Registration is just a shortcut that hides implementation details.  (Yes, there do exist some notable functional differences between the two, but that's just a shortcoming of both, not a fundamental difference in the model)

 

@Scatterplot -- as an excercise, can you create the same diagram, just with a static reference to `Value 1`, wired into a `Register for Events`, wired into the Event Handler Structure? Post that snippet, then let's use that as an explicit example to the "wireless" model of Static Event Registration.

  • Like 1
Link to post
Share on other sites

This one bit is not quite correct. You're thinking about multiple Event Handler Structures binding to a shared queue created by a single Register For Events Node. That's the scenario that produces undefined behavior. (Not just unpredictable behavior; truly undefined behavior)

Thank you very much for the correction, I've edited my previous post.  For answering several questions in this thread I went and wrote code to confirm my assumptions.  When it came to answering that question I just assumed I knew what it would do but as you mentioned gave the right answer to a different question.

Link to post
Share on other sites

While I can't say for certain, I always assumed it registered for these static events, when the VI is started, before any code is executed.  In actuality it might be registering for the events before the VI is even ran, but for this discussion it doesn't really matter.

 

It definitely happens before code execution. I can't say with certainty exactly when it happens either (and indeed it's academic to this discussion) but if you peer down into the bowls of xcontrols, recall there's an event structure in there that magically gets signaled from a VI that isn't running. Something tells me that this registration is happening when the VI gets reserved, and execution/starting doesn't have anything to do with it.

Link to post
Share on other sites

but if you peer down into the bowls of xcontrols, 

Oh that reminds me, XControls have some kind of limitation when it comes to using user events, I believe you can't use user events at all, that are created from outside the XControl, and I wonder if when it executes and registers has something to do with this limitation.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.