User Event return value

[wiebe@CARYA]

The idea is to add a return value option to user events:

If there are multiple event registrations, the return value is passed through them. Pretty much like existing filter event.

Optional icing on the cake:

Spoiler

The Generate user event could be split up in a send and receive part.

A time out could be added to the receive as well. 

Waiting for return data could be optional. The data will still propagate though all registered event structures. 

Disclaimer

Spoiler

I've read all "User Event" search hits on the idea exchange. Closest\only related one I could find was Register-User-Event-as-Filter-event, which is mostly concerned about discarding the event. But the idea exchange search is terrible, so it could be right under my nose...

[drjdpowell]

Of course it could also be used to collect information from clients:

I don't think any workaround will do exactly this. And definitely not with so little code.

Just looked at this.   I usually do similar gathering of info in applications done with Messenger Library.  You code is slightly more complicated, because your loops need to build an array; mine just reply to the "get info" message with their reference.  I also do "Scatter-Gather", rather than "Round Robin", though that only matters if the actions take considerable time.  And I get the array of references in a defined order (order of the addresses) which usually matters; your round robin is undefined order.  And I have the option of doing this in either a blocking or asynchronous fashion.

[wiebe@CARYA]

I'm doing this: "Hey, group of unknown size and unspecified people, do this, and reply when you're all done"

So who defines "this".

That is, who presents the API for the functionality. That is who implements the optional filtering. That is who is aware of whether anyone has added filters or not. And, in the case of a non-LV-Native solution, does the work of maintining that filter list.

The clients that register define what "this". Who else? With notifiers, don't the modules define what "this" is?

I don't see how this is different.

Not sure how non-LV-Native solutions are related, or what it actually means. Do  notifiers work for non-LV-Native solutions? 

It's got nothing to do with the sender at all. Whether you use Queues, Notifiers, Events or whatever.

If there are 0 listeners, there's no "this" and the request fails. "this" only becomes an actual thing when there is at least 1 listener. In your case, "this" is "Key Down" (tied to a UI action), NOT "Key Down?"

There is NO REQUEST. IT CAN'T FAIL!

You send data, and it's handled or not. You get the data back anyway.

The User Event is the API. When registering, you get the data, and optionally set the data. That's the entire API needed. That's right, no notifiers, queues, 2nd user events or scary frameworks required...

In my example "this" is most definitely "Key Down?". Not sure where "Key Down" comes from.

Who does the maintenance of the filter list? LabVIEW will keep a list of registered users, just like it handles multiple registered filter events. If you register, you get the user event, if you stop or unregister, it's removed from the list. 

In my previous two examples, how would that work with a notifier and flexible clients?

Module X creates and registers for Event "Key Down". Module X offers a way to add/remove filters for this event (user code). The EventData for "Key Down" includes a notifier (datatype not tied to the input data of the event). Module X makes this User Event available via some otherwise unspeficied path.

Another module Y accesses this information, sends an Event "Key Down" to Module X. An integral part of sending this event is creating a new notifier (If it wishes to receive a return value) and sending this notifier refnum as part of the Event Data. Module X receives the event, filters according to whatever filters are present (via whichever method it wishes) and when finished sends data back via Notifier to the module Y. Module Y defines how long it is willing to wait for the data. Once Module Y has either received the return values via notifier or it has timed out, it destroys the notifier.

That is so much simpler than the proposed idea, that would give this functionality immediately. /S, in case that isn't clear. 25 minutes wasted on boiler plating.

Instead of simply getting a user event to use, the modules now need to "play nice". Register, unregister, don't get aborted (by the program or the programmer aborting the VI). All enforced rules to play by.

And you don't get the data propagation from one client to the next. Guess we'll trough in a DVR?

[wiebe@CARYA]

> You code is slightly more complicated, because your loops need to build an array; mine just reply to the "get info" message with their reference.  I also do "Scatter-Gather", rather than "Round Robin", though that only matters if the actions take considerable time. 

This took me 5 minutes to make in LabVIEW and Paint. If this was in LabVIEW, it would be faster.

As this is less complicated with the message library, could you post an image of the solution for comparison?

[drjdpowell]

As this is less complicated with the message library, could you post an image of the solution for comparison?

Didn't time it, but 5ish minutes:

Added later: by "simpler", I really just mean that my loops don't need to be written to build an array.  In other words, they don't need to be explicitly designed to participate in a round-robin interaction.  

[wiebe@CARYA]

I disagree that that is less complicated. But it's not as complicated as I expected.

A few other concerns...

Adding a new client would be more complicated. The top part would need to be signaled by the new client to be added to "Addresses".  For the native LabVIEW solution, a new client would only need the user event. It would not involve the 'server' at all.

What happens if a client dies? Would the server wait for a time out? If done well (and I expect it to), the low left VI will create a reference, and that reference stops existing, so the request will know.

OT: Is "varient" a typo? I'd expect "variant"...

[drjdpowell]

Adding a new client would be more complicated. The top part would need to be signaled by the new client to be added to "Addresses".  For the native LabVIEW solution, a new client would only need the user event. It would not involve the 'server' at all.

But I would view that as a weakness.  Somebody should be clearly in charge of this whole process.  That thing should be able to message the Server to add the new address.   And sending messages is no more complicated than passing a User Event around, if you have a good messaging system.  

What happens if a client dies? Would the server wait for a time out? If done well (and I expect it to), the low left VI will create a reference, and that reference stops existing, so the request will know.

Why would it die?  Out-of-memory or something?  That would invalidate the address, which would throw an error on the send.  If it happened during execution of the action then the Scatter-Gather would have to timeout.  

[wiebe@CARYA]

Adding a new client would be more complicated. The top part would need to be signaled by the new client to be added to "Addresses".  For the native LabVIEW solution, a new client would only need the user event. It would not involve the 'server' at all.

But I would view that as a weakness.  Somebody should be clearly in charge of this whole process.  That thing should be able to message the Server to add the new address.   And sending messages is no more complicated than passing a User Event around, if you have a good messaging system.  

I've noticed you find that a weakness. I like it to be simple. Perhaps at the expense of robustness (although I doubt it).

What happens if a client dies? Would the server wait for a time out? If done well (and I expect it to), the low left VI will create a reference, and that reference stops existing, so the request will know.

Why would it die?  Out-of-memory or something?  That would invalidate the address, which would throw an error on the send.  If it happened during execution of the action then the Scatter-Gather would have to timeout.

It would die for instance because I'm debugging and aborted the VI.

I now wanted this because I'm implementing a control. Running in a SubPanel, as an XControl didn't suffice (don't get me started).

So, the subpanel control is simply started by running a VI that gets the subpanel reference. It would be very convenient if the user of the control could simply register for a Key Down? user event that my control exposes. In the event structure, there would be no mistake possible. Add the user event, and it's clear what you can do.

It would allow me to design my custom control so it behaves almost exactly as a real control.

As I mentioned, this could be done by supplying a class that does the filtering. But the custom control is a grid control, and it can contain 4 mln items. Each item could have it's own filter. It would be convenient to simply leave it to the user of the control. (S)he can then base the filtering on the activated row\column, value, whatever.

[AristosQueue (NI)]

> To me, and a lot of users, AF is just a way to add a lot of

> complexity. I'm looking for simplicity.

Agreed. We continue to work on ways to make the right way simpler. Have you seen channel wires? Have you tried using the messenger channel with a parallel For Loop to create an arbitrary number of listeners that can reply asynchronously back to the caller? There's a lot of power there that may solve some of your issues. Research continues, but it is all on the line of trying to make the asynch responses easier to write, not on making synchronous responses easier to write. It's the same reason we put time into making wiring easier and not into better sequence structures.

[wiebe@CARYA]

Can I dynamically add listeners to a channel wire?

[AristosQueue (NI)]

You saw the presentation from JeffK just now. The short answer is "yes, but probably not as flexible as you're hoping with the tech that is out right now."