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

[Intaris]

If you could create a single user event "A" that allowed registering "A?" and "A", that would work.

Isn't that actually part of the idea I linked to?

Edit:Hmm, no , maybe I gave the wrong link.

Edit Edit: No, it's the correct one. I had also looked at https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Event-When-User-Event-Becomes-Invalid/idi-p/3780357 and remembered that the registration for a user Event offered more than one event. I connected these two in my mind to the point where I imagined the Filter event being available on the right-hand pane of possible events for the user event, not the "Event destroyed" as shown in the second post. AQ mentions this exact point, that it would be possible, when registering for the user event to choose between the event itself or the filter.

You are then free, in the non-filter event, to send back whatever you want via whichever channel you choose (As previously stated, my preference is a notifier embedded in the event data).

The start of the non-filter event and the end of the last filter event are, for all intents and purposes, equivalent in this case. Unless nobody is handling the non-filter event, which would be a weird design choice.

[wiebe@CARYA]

>You are then free, in the non-filter event, to send back whatever you want via whichever channel you choose (As previously stated, my preference is a notifier embedded in the event data).

That is what I am trying to avoid.

If there is no registered client, you'll wait forever. If you don't know how many clients there are, you don't know how long to wait. You'll need to manage that, something that is not needed with this idea.

The event mechanism would handle this fluently, without any caveats.

[wiebe@CARYA]

>The start of the non-filter event and the end of the last filter event are, for all intents and purposes, equivalent in this case. Unless nobody is handling the non-filter event, which would be a weird design choice.

I really don't get that.

The receiver will get all notifications, but each client won't get a propagated (filtered) result.

0 filters seems like a perfect option to me. My VI offers the option to add a filter. No filter will result in the default behavior. For instance, my subpanel activates a string. The optional filter could filter out illegal keys. Or not. It's the users choice. 

[wiebe@CARYA]

>If you could create a single user event "A" that allowed registering "A?" and "A", that would work.

Isn't that actually part of the idea I linked to?

Edit:Hmm, no , maybe I gave the wrong link.

Edit Edit: No, it's the correct one.

"Idea is to implement to LabVIEW possibility to handle User Event as Notify event (as it is done now), and as Filter event."

After the recent edit, that seems to be the same.

Not sure why both you and AQ really liked (and kudod) that one, and really hated this one... The main difference (certainly after the recent shift) is my idea has better graphics. And of course his idea solves AF problems, not real problems 😂...

For it to work out for me, I do need the sender to get the result in the same place where it was send. If I want to forward a real "Key Down?" event to "My Key Down?" event, I need the filtered data ("My Key Down") in the real "Key Down?". I can't handle the "My Key Down" event, as I lost the opportunity to use the data in the "Key Down?" event. I don't thing there is a way to test if a nested event structure will work, as this would be a novel construction.

EDIT:

One major difference is this:

"Currently one could solve it with case structure or something like this, but while having Filter User Event, it would be possible just to filter out event, and drop it."

This, to me, implies a Discard? option in the filtering event. That would not really fit my use case. I don't want a Discard? option so each client can break the chain.

[Intaris]

Not sure why both you and AQ really liked (and kudod) that one, and really hated this one...

Two reasons (For me, currently, based on my understanding in this moment in time, I don't want to speak for AQ at all of course)

1. User Events with built-in return values (mirroring the event data itself). I just do not like this idea. The limitation of the datatype for the return values serves no purpose whatsoever for any of my applications. This is aside from the obvious deadlock issue which will obviously occur on a regular basis.
2. I may misunderstand but you seem to want to be able to programmatically fire filter events. I don't think this is a good idea at all. Filter events get called automatically (if such a handler has been registered) when the main event gets called. If someone calls Event "X" and there are filter events "X?" registered, the "X?" events fire before "X" and "X" gets the filtered data.

I don't hate this idea. I think you're taking our comments way too personally. Speaking for myself, I have a very hard time understanding what it is you actually want to achieve. As such, I'm trying to counter something (i.e. give alternatives) which despite reading the posts several times, is not completely clear to me. But what is clear to me is the parts of the proposed solution (whatever the reason for them is) which do not seem like a good addition to the language.

Your posts use terms like "receiver", "client"  and "sender" and I still don't quite understand who these are in your grand scheme of things. I thought I did, but applying my understanding to your posts does not lead me to any kind of sensible understanding. And that confuses me because I know you know what you're talking about, you're no noob. I'm sure there's an interesting point in all of this somewhere (which is why I keep posting trying to narrow that down) but for the life of me, I currently cannot find it. It may simply be a communication issue (no pun intended). I'm not here to attack your idea, I'm here to try to understand better.

[wiebe@CARYA]

I won't take anything personal. This would be a good discussion over some beers. I do fully understand how things get lost in translation. Right now, I don't understand how you don't like my filtering event, but do like the idea that's actually called add filtering event. I do appreciate the discussion, although it seems we're talking in circles. The discussion is all that's left, because changes of this ever happening after this discussion are slim...  

I need to make my own controls, simply because NI won't.

For instance, a grid control. But that's not really relevant.

What matter is, like LabVIEW controls, it would benefit these controls if the users of that control had ways to filter the control (events). Just like a real control.

It's really really hard to make a decent GUI in LabVIEW. I'm stuck with either the limitations of LabVIEW controls, or the limited tools that are given (lack of useful events, properties and abilities).

My control might end up with all filtering events 'real' controls have. Having to add notifiers and what not for each event is just lots of wasted work. And the result won't be nearly as good as a real control. I'd also have to put this in the manual...

With this idea, at least that part wouldn't be terrible. For me and the users of what I make.

[Intaris]

I'm with you 100% on the need for better control customisation.

When this virus stuff is finished, I look forward to discussing it over a beer. Or two. 😋