The mega event strucuture vs. nested event structures

[pandaman]

Hello fellow LabVIEW wirers,

I am "renovating" a relatively large program I have made in the past with new features. I am adding alot of buttons in the process, which I plan to control with event cases. Some buttons lie directly on the front panel, while some are in a tabbed interface (a few buttons for each tab). On the block diagram, I have an event structure surrounding the case structure (for event timeout=100ms) which handles events for the buttons outside the tab. The case structure is for the tabbed interface. I am thinking of either placing a set of nested event structures (for each case in the case structure) to handle the tabbed buttons OR make the outer event structure handle these buttons. Which is more CPU-time efficient? I would think the nested version (since the outer event structure would not have to check for events that do not apply for all tabs), but since the nested one would be in event case timeout, I am uncertain.

If my description is unclear :headbang: , I can upload an example.

Thanks,

Mayur

[mross]

Hello fellow LabVIEW wirers,

I am "renovating" a relatively large program I have made in the past with new features. I am adding alot of buttons in the process, which I plan to control with event cases. Some buttons lie directly on the front panel, while some are in a tabbed interface (a few buttons for each tab). On the block diagram, I have an event structure surrounding the case structure (for event timeout=100ms) which handles events for the buttons outside the tab. The case structure is for the tabbed interface. I am thinking of either placing a set of nested event structures (for each case in the case structure) to handle the tabbed buttons OR make the outer event structure handle these buttons. Which is more CPU-time efficient? I would think the nested version (since the outer event structure would not have to check for events that do not apply for all tabs), but since the nested one would be in event case timeout, I am uncertain.

If my description is unclear :headbang: , I can upload an example.

Thanks,

Mayur

Yes, that sounds interesting....I seem to recall the nested events are not supported however.

Like mashe quotes from Heinlein, and paraphrased by moi, after listening to the experts say why not, do it anyway.

Mike

[didierj]

To handle events from buttons/values/enums... you only need an event-structure (witout timeout) surounded by a while loop. All the events of a FP will be handled by the same event structure independently of their position in/out of a tab/cluster/...

Nesting events is possible but error prone, and doing it just because the controls are nested (in a tab) is IMHO really bad wiring.

Use the timeout case for things that have to be done repeatedly (eg. update a time indicator or pressure/temperature/... indicator), but NOT to poll controls, for that you have the event structure.

As reference also check the examples.

EDIT: ...yes, please upload your example

Didier

[Guillaume Lessard]

Some time ago I made the mistake of using multiple event structures to handle events from multiple tabs. Since each tab represented mutually exclusive modes of operation, I thought it was a good idea. I ended up with a really painful program to deal with, and when the inevitable shared-by-all-modes control was needed, all kinds of issues came up. I will have to rewrite it with a single event structure, not that I know exactly the right approach to accomplish it with minimal work...

Unless you have a really clever way to deal with with multiple event loops, I'd say don't do it!

(...and you do find a way to make it work well, I'd like to see it, too!)

[crelf]

I seem to recall the nested events are not supported however.

It's supported, but most often not a good idea. One of my colleagues used a nested event structure to conditionally determine if a user had mouse-downed on an image indicator, and then track the mouse position - it worked realtively well once all the appropriate precautions were taken into account (eg: should you lock the UI during the operation of the outer or inner event structures? Can you know with absolute certainty which event structure will grab and event? Can you use dynamic registration of events instead? etc).

All that aside, I've got to agree with didierj - it doesn't sound like you need to nest event structures at all.

[JasonKing]

I can see the desire to nest event structures here to kind of represent the state machine, but the above posts are correct - it generally is a bad idea. I'd suggest one of two alternatives:

1) Have one event structure registered for events on the important controls on all tabs. The visibility of the controls on each tab should ensure that event-handling cases don't execute at an inappropriate time

2) Have one event structure that at any given time is only registered for events on controls on the visible page of the tab control. On value change of the tab control, dynamically unregister for controls on old page and register for controls on new page. Make sure to turn on panel-locking for the tab control:value change event case or you will have a race condition.

Personally, I'm a fan of #2, but it's a little bit harder to maintain and a little less self-documenting.

J

P.S. Regarding the "timeout"....I think many people forget that this timer resets each time the event structure gets an event, so it's possible for the timeout case to starve if, say, the ES is watching for mouse move events on the top-level VI and the user is vigorously moving the mouse. It may be better to have a parallel loop with a WAIT in it if you want to perform some action at a regular interval.