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

[Michael Aivaliotis]

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.

[ShaunR]

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 Will look again

 

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

Edited August 10, 2013 by ShaunR

[Michael Aivaliotis]

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

 

Thanks, I added it to the list.

[Mads]

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.

[shoneill]

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

[hooovahh]

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.

[Bean]

• 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?

[hooovahh]

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 August 15, 2013 by hooovahh

[Mellroth]

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

[hooovahh]

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.

[infinitenothing]

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