DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Processing the same "user" event in 2 different event structures in the same VI

Solved!
Go to solution

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.

0 Kudos
Message 1 of 6
(3,412 Views)
Solution
Accepted by topic author Rafal_Kor

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.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 2 of 6
(3,407 Views)

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

0 Kudos
Message 3 of 6
(3,404 Views)

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.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 4 of 6
(3,390 Views)
Solution
Accepted by topic author Rafal_Kor

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

 

 

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 5 of 6
(3,366 Views)

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.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 6 of 6
(3,361 Views)