09-25-2018 02:14 PM
I know I shouldn't code the main.vi in any module such that the same user event in processed in 2 places, for example the EHL and the Helper. I think I've heard Fab in one of her videos saying that having 2 event structures in 1 VI was OK, as long as the 2 event structures weren't processing the same event. So why does it work when I process the module stop event in both EHL and in the Helper of the main.vi at same time. It shouldn't work but it does, can someone please tell me why? It works every time I've tried it so far. And of course when i registered for the user event I did not fork the registration wire.
Solved! Go to Solution.
09-25-2018 02:52 PM
Multiple event structures in 1 vi can all process the same user event (as you noted - don't fork the refnum), but what you don't want to do is handle the same user interface event (ie. a control value change, mouse over, panel close event) by statically selecting it in multiple event structures in the same vi. I believe you can get away with handling those in multiple event structures in the same vi if you register it dynamically.
09-25-2018 03:01 PM
@Taggart wrote:
Multiple event structures in 1 vi can all process the same user event (as you noted - don't fork the refnum), but what you don't want to do is handle the same user interface event (ie. a control value change, mouse over, panel close event) by statically selecting it in multiple event structures in the same vi. I believe you can get away with handling those in multiple event structures in the same vi if you register it dynamically.
I obviously must have missed the "interface" part of the events that Fab was talking about. Thank you for clarifying.
09-25-2018 04:27 PM
Perhaps someone more knowledgeable will chime in, but I believe the real issue is the static registration. It has something to do with how the "event queues" are created behind the scenes. When something is statically registered, only 1 event queue is ever created, versus every time you use the register for events node another event queue is created.
09-26-2018 09:08 AM
Sam got it, thanks Sam!
It all has to do with the creation of event handling engines.
The reason why forking the registration wire doesn't work is the same reason why handling a static event for a control value change in two different event structures doesn't work. It is as if we are attempting to dequeue from the same event queue in two different locations. Except, it is not exactly the same as a queue because if the two event structures happen to be ready to process the event at the same time, it might work, but "might" is how race conditions get created and we need certainty that it will work. So in summary:
1. Use an event registration node per dynamic event structure case (meaning don't fork the wire).
2. Register to handle static events in only one event structure per block diagram.
Sam is correct that you can get around the second restriction by registering dynamically to a control event (wire the control reference to the event registration node and you will be able to select the event type). Please note that you can register to VI events as well but not all of them work in two places, you will have to try them.
Regards,
Fab
09-26-2018 11:49 AM
Thanks for the confirmation Fab! It's been a while since I've dealt with any of those issues, so glad to see that my explanation hit the mark.