Jump to content
Michael Aivaliotis

New Events features in LabVIEW 2013 (Flush Queue, High Priority Events, Event Inspector Window, etc)

Recommended Posts

I did a presentation at NIWeek 2013 on the new user event features in LabVIEW 2013. I will post a link here when it's ready for online consumption. For now, I'd like to start a discussion on what all the LAVA members think of the changes and additions. If you have questions on how one feature or another work, please post here and we'll get it answered.

 

To summarize, here is what was changed, added:

  • New - Event Inspector Window (you're gonna love this!)
  • New - High Priority events
  • New - Flush Event Queue Function
  • New - VI Scripting methods and properties for events
  • New - Mouse Scroll Wheel Event
  • Improvements to the Edit Events Dialog:
    • It's now resizable (Finally)
    • You can filter search the list of event sources and events. For easy navigation.
    • You can limit instances of the event in the static queue (Similar to Flush Queue function)

    [*]Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal.

Let's keep this positive. We all need to learn how to use these new features and how to integrate them within our frameworks. I know a lot of you are using user events as the main communication mechanism for your processes and modules. Let's figure out how to make our code better with all this new cool stuff.

  • Like 2

Share this post


Link to post
Share on other sites

New - Event Inspector Window (you're gonna love this!)

- Never had a need for this, but it may come in handy if you don't know what events you are firing ;).


New - High Priority events

- Don't have a use case at the moment. But I can see edge cases where it may be useful.


New - Flush Event Queue Function

- I've always considered flooding event queues as bad and lazy programming, so I think this will just let bad and lazy programmers off the hook.


New - VI Scripting methods and properties for events

- Good for tool-chain developers. But no real use case for me.


Improvements to the Edit Events Dialog:

- Didn't notice :D Will look again

 

You forget the big one - MOUSE WHEEL :worshippy: . By far the most useful, just a shame it's the only one.

Edited by ShaunR
  • Like 2

Share this post


Link to post
Share on other sites

The first use case I thought about for the new functionality was that I could use it for things like cursor moves and window resizing. Those are events that typically fire in rapid succession, require fast reactions, but only to the last occurrence.  Prior to 2013 I've done this by reducing the handling of each event into setting a flag, which would then trigger a flag-resetting process elsewhere. This does not produce the same responsiveness though, and adds (what should be) unnecessary code.

Share this post


Link to post
Share on other sites

I can think of a few use cases also.

 

Aside from thi following being probably a bad implementation....

 

I have a process which transfers a relatively large data set between a background process and y UI via User events.  These data packets can be several megabytes in size and the ability to ENSURE that only a limited number of these events can be stored in the queue helps me keep a cap on my RAM requirements without having to implement a handshake protocol.

 

Bot mouse move and resize events are the clear winners with the new implementation.  I wonder if it also works with XControls, limiting the "backlog" which can sometimes cause a very disjointed XControl update experience with the XControl sometimes still updating after the host VI has stopped running.....

Share this post


Link to post
Share on other sites

To summarize, here is what was changed, added:

  • New - Event Inspector Window (you're gonna love this!)

This is great, but I have a home grown one that works with user events, and it works at run time as well.  So I have one window that will show me the last N number of user events generated between my Actors, and can then display the data (using the Variant Probe).  So if something goes wrong in the application I can see the chain of events that caused it.

 

  • New - High Priority events

Neat but I think I will only use this on shutdown.  It isn't very often that I find a queue of events pilling up that I would need this but it's nice to have.

 

  • New - Flush Event Queue Function

Neat again, but I don't think I'll need it.  Possibly to flush away extra window resize events, as already mentioned but I doubt I'll need it.

 

  • New - VI Scripting methods and properties for events

Finally.  I posted on Lava a while ago when I found this "was not implemented".

 

  • New - Mouse Scroll Wheel Event

Finally.  The ability to zoom a graph with the scroll wheel sounds like a feature that all graphs should have.  Also when doing things like having a scrollbar not attached to a control you can now have more flexibility on what happens when a user scrolls on top of a cluster (it can then change the scrollbar value)

  • Improvements to the Edit Events Dialog:
    • It's now resizable (Finally)
    • You can filter search the list of event sources and events. For easy navigation.
    • You can limit instances of the event in the static queue (Similar to Flush Queue function)

All neat and I'm sure will help develop code faster.

  • Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal.

I never ran into this issue.

Share this post


Link to post
Share on other sites
  • New - Flush Event Queue Function

 

Did a project in 2007 where a slider was linked to the amplitude of an analog output.  Sliders generate thousands of events which overfed the consuming hardware actor.  Each time I got a slider-value-change event, I unregistered, updated the AO, and re-registered for value change.  There were other requirements with this method which were necessary to ensure that I got the latest value when the operator was finished dragging.  Maybe this challenge would be better handled today by flushing specific events instead of managing registration?

Share this post


Link to post
Share on other sites
Did a project in 2007 where a slider was linked to the amplitude of an analog output.  Sliders generate thousands of events which overfed the consuming hardware actor.  Each time I got a slider-value-change event, I unregistered, updated the AO, and re-registered for value change.  There were other requirements with this method which were necessary to ensure that I got the latest value when the operator was finished dragging.  Maybe this challenge would be better handled today by flushing specific events instead of managing registration?

I agree that this can be a place where the Flush can be used, but my work around was when the slider had a value change all it did was set a boolean true in a shift register.  This boolean would set the event structure timeout to 0ms.  Then in the timeout case I would perform the analog output, then set the boolean in the shift register back to false.  The timeout case only gets executed when there are no other events in the event queue.  So I would only set the analog out after the 100s of value changes had stopped for 0ms.  This would reduce the number of analog output commands from 100s to on the order of 10 or so and it would always set the last value.

Edited by hooovahh

Share this post


Link to post
Share on other sites
I agree that this can be a place where the Flush can be used, but my work around was when the slider had a value change all it did was set a boolean true in a shift register.  This boolean would set the event structure timeout to 0ms.  Then in the timeout case I would perform the analog output, then set the boolean in the shift register back to false.  The timeout case only gets executed when there are no other events in the event queue.  So I would only set the analog out after the 100s of value changes had stopped for 0ms.  This would reduce the number of analog output commands from 100s to on the order of 10 or so and it would always set the last value.

 

I don't think flushing events would solve this, e.g. how can you be sure that the last element isn't already in the event queue, meaning that flushing will remove the most important element you actually want to handle.

 

Letting the timeout case handle the last event can be very neat, and I use this very often in small UIs. Another option is to use a size limited queue used with the lossy enqueue primitive. This can be handled in the timeout case, or in a separate consumer loop depending on the requirements.

 

/J

Share this post


Link to post
Share on other sites
I don't think flushing events would solve this, e.g. how can you be sure that the last element isn't already in the event queue, meaning that flushing will remove the most important element you actually want to handle.

Very true, you could flush it then process the last one that was flushed.  I haven't used the new Event Features yet but I assume after flushing it will return all the events that were flushed like a flush queue.  Then if 100 value changes come in you flush them all and process the analog output on the last one.  There's a bunch of ways of working around this and the timer idea neil mentioned is another I have used.

Share this post


Link to post
Share on other sites

I don't think flushing events would solve this, e.g. how can you be sure that the last element isn't already in the event queue, meaning that flushing will remove the most important element you actually want to handle.

 

Letting the timeout case handle the last event can be very neat, and I use this very often in small UIs. Another option is to use a size limited queue used with the lossy enqueue primitive. This can be handled in the timeout case, or in a separate consumer loop depending on the requirements.

 

/J

You can tell the flush event queue to flush all but the last one. It also outputs the number of events that were flushed so you can use that to detect you're at the end

ykKlxS1.png

Share this post


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.