Queued Message Handler Template - User Event Registration

[Jacobson-ni]

I like it. If I understand user events correctly I would agree with Kevin to keep the creation and registration separate as well.

My understanding is that if you want to add another event handling loop somewhere later in this application which is also looking for this global stop user event, you would have to register for the user event separately before that event structure instead of using the same registration refnum. I think the example as-is would do a better job at showing how there should be a unique Register for Events function for each event handler. Probably doesn't matter either way but those are my thoughts.

[crossrulz]

What I typically do is have a library for the event with an Action Engine to keep the reference for the User Event.  I then have public methods for registering for the event and sending the different commands (only 1 in this case), and another one for destroying the User Event.  Then anybody can send the message and it (almost) forces a different registration for each module you have.

But for the sake of the example, I would say Darren's fix would be the best solution.  I would rather not complicate an example with libraries, etc.  Now for project templates, that is a slightly different story.

[Darren]

This is the QMH project template. But I doubt I'll get easy buy-in on an expansive change like what you describe, which is why I'm hoping the Merge Errors fix is a good compromise.

[Darren]

I have filed CAR 603854 to add the Merge Errors to the QMH Main VI in a future LabVIEW release.

[mcduff]

I typically use User Events in multiple loops and subVIs. To make sure those VIs are active and listening I use a modified version of something Hoovah created. In the example I am waiting for 3 loops to become active, a UI, Instrument, and Data loop. The vi will run until it timeouts or the active event loops are found. See snippet and subVI. Link to Hoovahs orginal version in VI.

Cheers,

mcduff

[ChrisStrykesAgain]

CAR 603854 was fixed in LabVIEW 2017. See the 2017 LabVIEW Bug Fix List for details: http://www.ni.com/product-documentation/53584/en/

[labmaster]

As the beginner of user event, I have a question on the design pattern.

I focused on the Exit logic in Queued Message Handler design pattern of Labview (2018).
When exiting the program, the exit event was sent by using user event from the below loop to event loop, and then received again in the below loop .

Is there some special reason or advantage for that?

I am studying the user event but I cannot imagine when I can use the technique in my level.

labmaster.

[Yamaeda]

---

@crossrulz wrote:

My solution would be to have the Event Initialization VI also output the registration.

---

Though some versions ago (i think it works better now), changing the registered events broke the indicator forcing you to recreate stuff. This could be quite annoying if you passed it through some VIs.

I think it works a lot better since ... 2015(?)

/Y

[Yamaeda]

@labmaster wrote:

I focused on the Exit logic in Queued Message Handler design pattern of Labview (2018).
When exiting the program, the exit event was sent by using user event from the below loop to event loop, and then received again in the below loop .

---

I'd assume it's a fail safe/double whammy. Regardless if the command initiates in the event or queue part, it sends to the other to make sure it stops. This is probably in case something else than the intended commands stop the loops.

/Y

[billko]

I guess if you have multiple ways to stop the application and they all use the same user event, the application will stop "the same way" all the time.