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

[wiebe@CARYA]

>> Guess it's "power to the programmer"

>> versus "protect the noobs" once more...

>Were you trying to make me laugh? You succeeded.

>No.

>The power programmers were (are) the ones building the messaging frameworks. They were the ones losing months of work to bugs they could not explain.

>The novice programmers weren't even involved.

Isn't avoiding bugs the key feature of power programmers?

To me, a messaging framework would be a lot easier if user events had a build in to get return data. It is what they are all doing, but in a more difficult way (queues, notifiers, what not).

>They were the ones begging for something better.

What made them stop?

[wiebe@CARYA]

>Maybe the problems I'm generally dealing with are so different to yours that I have trouble seeing the benefit of this at all..... Care to outline a specific use-case?

The unknown number of registered users is just a bonus.

Every time you want to send a client a message with a user event, and want to get a result, this would be useful.

Even if you know the number of registered clients, this would avoid a work around (queues, notifiers), saving work.

Queues\Notifiers are only a partial work around, for limited situations (known listeners). If you send a queue, and the listener stopped, you're waiting for a timeout. With return values, you'd simply get unaltered data.

My specific situation that triggered posting this is very simple. I have a VI in a subpanel that reacts to LabVIEW filter events. I want other VIs to handle the events (filtering the data), send back the result, let the original . Very simple, but more work that I want to do. Of course, there could be multiple VI's. Dynamic Dispatch would do this in some situations. But that would require a rework.

[drjdpowell]

1. It's a strange messaging pattern.  Normally, patterns have an initiator of a request and a response to the request.  In the Event paradigm, the send event is the response to the event registration "request".  But you are here using it to initiate a request to your own event requestors, requiring a response to your response.  What is the use case?

[Intaris]

So what you want is to daisy-chain your event handlers, to build up successive pieces of functionality to implement a set of functionalities.

The combination of this with "sending back" and "let the original" I don't quite get.  The only one who can get something back is the one who sent the original event in the place. The send event : receive answer is an inherently 1:1 relationship. Why doesn't this work with notifiers?

Why not define a series of handlers as objects and "register" them with the final event structure. That way you actually regain control over the order of execution of the individual steps.

[drjdpowell]

Posted by accident.

[AristosQueue (NI)]

> > They were the ones begging for something better.

> What made them stop?

The introduction of the Actor Framework. Even the users that don't like the AF generally moved to asynchronous messaging as the "right way" to do this kind of messaging. The number of people now asking how to solve problems in synchronous messaging, such as this idea, has nearly dropped off my radar in the 10 years since AF introduction, whereas I used to get a request for help about once a week from some major user of LabVIEW in the form of "our framework for controlling our parallel test system keeps deadlocking or quitting unexpectedly for reasons we cannot fathom."

[wiebe@CARYA]

>So what you want is to daisy-chain your event handlers, to build up successive pieces of functionality to implement a set of functionalities.

Nothing new here. Filtering events seem to work exactly like that.

>The combination of this with "sending back" and "let the original" I don't quite get.  >The only one who can get something back is the one who sent the original event in the place. The send event : receive answer is an inherently 1:1 relationship. Why doesn't this work with notifiers?

The Generate event sends the message, and gets the result back ('delayed' or not).

It's not a 1:1 relationship. Or rather, it doesn't need to be 1:1 (that would work with notifiers). It could be 1:0..n, where n is unknown to the generate event.

Each registered event gets the data, and puts it back. When all registered events have been triggered, the data is returned. Again, exactly like a filtering event.

With a notifier, each registered event has an obligation to register to the sender. With this idea, each client would only need the user even, register, and the sender wouldn't need to know if the client is still there or not. The event handling takes care of that.

>Why not define a series of handlers as objects and "register" them with the final event structure. That way you actually regain control over the order of execution of the individual steps.

I don't need control over the order.

Each time another event registers, or stopped, it needs to communicate this. Now this is a source of deadlocks, race conditions, live locks, and what not.

This is how simple it could be:

Simple as that.

If filters are added: simple. If filters are stopped: simple.

No VIs, references, notifiers, type defs, or other boilerplating involved. Just the user event.

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.

No workaround will be easier to debug. If you have a deadlock, at least it won't take months to find it. 

[wiebe@CARYA]

>> > They were the ones begging for something better.

>> What made them stop?

>The introduction of the Actor Framework.

I know. I should have added /s 😉.

To me, and a lot of users, AF is just a way to add a lot of complexity. I'm looking for simplicity.

This one won't let me go (we really need the quote to work in the idea exchange):

>> Guess it's "power to the programmer"

>> versus "protect the noobs" once more...

>Were you trying to make me laugh? You succeeded.

>No.

>The power programmers were (are) the ones building the messaging frameworks. >They were the ones losing months of work to bugs they could not explain. They were the ones begging for something better.

>The novice programmers weren't even involved.

I guess it's a matter of perspective. I can't quite relate to your perspective on this one.

For me:

Power programmers could use this when appropriate, saving time.

Power programmers wouldn't (have to) use this if they are afraid of deadlocks.

Power programmers apparently find workarounds that create bugs that take months to find anyway.

This idea, if anything, will make it easier to spot the bug, for power users. And as it's faster to implement with this idea, you can get into bug fixing faster 😁.

I really can't see how adding an option would make the lives of power programmers harder...

I do see how extra options would encourage novice programmers to fail. 

So to me, this cripples power programmers, only (I assume) to protects novice programmers.

It's "VI-property-subpanel-ref " all over again. I still waste time having to make workarounds.

[Intaris]

Why even use events for this?

Events would not be my method of choice for this use case. Why not use an action engine with "register" and "unregister" and "filter" capabilities for individual actions (VI refs, OOP, whatever)? Then simply call the action engine in your UI filter event....

[drjdpowell]

I think the problem is that User Events are not a full messaging solution.  Events are an implementation the Register-Notify messaging pattern, but you need the Request-Reply messaging pattern.  User Events are not designed for this.  You would like to use the Notifications as if they were Requests, and so you need something to serve as the Replies.  So this idea is an attempt to extend events to have some kind of Reply mechanism.

The value of a Reply mechanism I agree with, but this is a poor way to do that, because Requests via Notifications are a poor idea.   They are the equivalent of "Hey, it's very important this is done right now. I sure hope somebody is listening to me and will do that thing, and will reply when they're done.  I'll just wait here and hope."  Real Requests are like "You, specific person, do this now, and reply when done."