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]

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

In Messenger Library I have things called "Watchdogs", which monitor and address and send a message when the address dies.   That can trigger logic like restarting the component that died.  I did that recently for an app that must run for months and had an unreliably dll that would kill the whole program.  I made a separate exe that connected over TCP (TCP address capability is built in to Messenger Library) and used a watchdog to detect when the address dies (which is near-instant when the app dies) and restart the app.

I do not generally do watchdogs just because I might deliberately kill things while debugging, though.  

[drjdpowell]

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

Doesn't sound simple to me, especially when you need to debug a problem in your filters and you forgot some obscure one you added a month ago.  Having an obvious place that handles everything to do with filters is simple.  

[wiebe@CARYA]

>You saw the presentation from JeffK just now. 

Only with one eye. I have deadlines...

I'm also not sure how the sender would know if all registered client is done. Except with some client registration mechanism, handled by the sender.

I'm still not convinced that how my idea is worse that these alternatives. Discarding development time of course.

It would solve a niche, but one that is hard to fill with alternatives. Actually impossible to fill completely.

I'm not looking for workarounds. I'll get it working. It's just frustrating that I have to do the work. I could be productive instead.

[drjdpowell]

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.

I don't understand what you're trying to do here, but if it is trying to look like a "custom control" then I see how you would need to plug in to the Event paradigm (i.e. be like a filter event).   

[wiebe@CARYA]

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

Doesn't sound simple to me, especially when you need to debug a problem in your filters and you forgot some obscure one you added a month ago.  Having an obvious place that handles everything to do with filters is simple.  

---

That I can make a mess doesn't mean I will make a mess.

Of course the filters will be added in a structured manner.

To me, creating a filter would be much less error prone. Simply add an event. No room for error. With any other system, there will be room for mistakes. Forgetting to register with the server, forgetting to unregister with the server, forgetting to call VI\notifier\whatever to send return data.

No existing alternative is this simple:

[drjdpowell]

Rereading, I realize I've wrongly interpreted what you want as being about interprocess messaging, rather than making a new custom-control design, with custom "filter" events.

In which case, I suggest preventing the User of your control from being able to have more than one registration for the "filter event".  So, only one filter.  Then you don't need this idea of round robin, and can implement a single reply. Does anyone ever actually use multiple registrations for a single filter event?

You could do this by returning, instead of the User Event, a pre-registered Event Registration.  Then the User cannot register for multiple event structures.

Actually, that won't work, as you need to know if the User hasn't registered at all.  Maybe your idea should be "Let us query a User Event to see if anyone is registered for it"?

[wiebe@CARYA]

I got a simulation\Proof of Principle\toy where the events (and just the events) acts as I'd like, misusing the only filtering event you can trigger from code that I could find.

Spoiler

Window Opened? can be triggered by hiding a closed VI FP.

Of course I'd have to register to Window Opened? events, not my own user event. I need a DVR, so all clients get to modify the same data. The DVR needs to be distributed... Window Opened? messages need to be filtered for my VI name.

But if clients register for Window Opened? (statically or dynamically) and the sender registers for Window Opened, all filter events are handled before the sender gets the result.

Please don't consider this a workaround... 

[wiebe@CARYA]

Actually, that won't work, as you need to know if the User hasn't registered at all.  Maybe your idea should be "Let us query a User Event to see if anyone is registered for it"?

Others suggested that. It won't be the quite same.

If you know that you have 1 client, there's no guarantee it's still there when you wait for it.

This will be a bug waiting to happen. One that will be very hard to find. I'm not sure how this will hunt me, but it will.

I can live with one client for now. But when proposing the idea as a solution, it made sense to generalize. It would be weird to suggest a user "filtering" event that only allowed 1 registrant.

[Intaris]

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Register-User-Event-as-Filter-event/idi-p/3798423

Why would this idea not solve your problem?

[wiebe@CARYA]

I've seen that one. There's an overlap, but it's not the same.

As I understand the filtering idea, it doesn't give the sender a return value.

Unless there is a deterministic way to make the sender get the filtering event last (even if clients registered after it), it won't help in my situation.

With build in filtering events, you'll always get the "event?" before the "event", for instance all "Key Down?" are fired before the "Key Down".

If you could create a single user event "A" that allowed registering "A?" and "A", that would work. That would effectively split up the Generate User Event and the "Get Data" past.

That might fix the main objection, the deadlocks.

But in my situation, it would prevent me from generating the event, and receiving the result within the event. A nested event structure might just work this time, but it will be nasty. I could live with that (beggars can be choosers).