@Intaris wrote:
@SteveChandler wrote:
More specifically is there something you couldn't do if user events did not exist in LV?
Yeah. Have a really neat and tidy asynchronous system up and running with tidy code.
As soon as your asynchronous process has it's own UI, User Events are the way to go. I usually have a single event structure firing off a queue or notifiers as required to a consumer loop for updating UI and other things.
I love User Events and find them optimal for most inter-process communications. Of course some applications require queues or notifiers (Like periodic checking of "Did the user quit this operation" actions) but per default, I go with user events.
Shane.
I have pretty much gone the user event route exclusively also. There are just too many benefits, and not enough drawbacks for me not to. On RT I find benefits, but where user events really begin to shine are within GUIs. The fact that loops can register for events they care about and all the queue creation for a single message to be copied to these different processes is abstracted from the programmer is a great time saver. It makes dynamic launching of different windows seemless -- you don't have to keep adding a queue to a list every time a new screen is opened; just register for the event that is needed and the rest is taken care of.
Another benefit of user events is, if no one is registered for an event, that event gets thrown away. This is my favorite feature of user events. What happens if you have a queue and no one is "listening"? Memory leak. User event, no one is listening? No problem. Let me give an example. I had an application that had about 18 subpanels on 3 different screens. I was constantly checking which screen was being shown and depending on which screen was open, I would queue up data to those sub panels. What a nightmare. Another option using queues was to have all screens running all the time and just hide them and show them. That way they were still dequeuing their elements in the background all the time. Eh, too much unneeded overhead. Enter User Events. When a window opens, it registers and gets data. When it closes, it unregisters. My main loop just spit out data all the time, it didn't care who was listening. User events decouple the sender and the receiver.
It should be noted, this type of behavior can be coded using native LabVIEW queues, and although I haven't looked into it extensively, I believe that's what the JAMA architecture does. However, since User Events already provide this functionality, I prefer to use them. I just hope that NI starts incorporating more of these concepts into their advanced training courses rather than just describing how "you can message back to your producer loop from your consumer in a producer consumer architecture."
One drawback (if it can be called that) is the command pattern is all but useless with this method. So, if you have been digging into the Actor framework, that concept won't translate well. This is due to the fact that multiple loops can get the same message. If a logging loop and a TCP loop both get the "xyz data" message and that message can only have one action associated with it, as the command pattern defines, well you're out of luck.
My .02. Yikes, that was longer than I thought it would be.
And to the question asked by the user who resurected this thread "Is a queue a superset of the notifier, in that it can stack up events?"
A notifier is basically a single element queue. In fact, one of my coworkers got an error while using a notifier and in the error description it talked about queues!
