Allow "Register for Events" to have a "Read events" version to unbundle user events

[BertMcMahan]

The dynamic events terminal accepts bundled Event Registration refnums, and you can use an Unbundle on the inside of the structure to access all of the events. This is very useful, and allows you to edit events dynamically during run-time.

The Register for Events terminal also accepts bundled User Events, registering them all at the same time. This is very helpful when writing code in which the User Events are generated in a subVI; you only need to present the User Events as a bundle on the output terminal.

The issue is that, if you have Registered the events as a bundle, you cannot access the individual User Events within the Event structure. This would be useful to have, for example, one event case modify which event structure a different event case listens to.

In the above case, it would be ideal if you could first unbundle the wire from the Dynamic Events terminal, then read all of the user events to which it is listening. This value would be a bundle (in this case, containing Event A and Event B), and you could wire "Replacement for A" into it.

Currently you can only replace both A and B at the same time, requiring you to keep track of what exactly is registered to each refnum separately.

[wiebe@CARYA]

Two easy solutions (at least).

1) Registers two user events, not a bundle.

2) Put the bundle in a shift register. Then you can replace one and reregister.

Not sure how the solution you suggest would look like. Never had this exact problem. Not saying it won't be useful, but I'm not convinced jet...

[BertMcMahan]

The issues it would solve generally incorporate a subVI generating the user events. In the example I gave, say Event A and Event B were generated inside a subVI; it's much neater to have a single wire coming out than two user events, and it scales with any number of user events. You could, of course, unbundle it and register for each event individually, but this doesn't scale well, and requires the user to add a new Register for Events function each time a new User Event is added. It's of course doable, but it uses quite a lot of block diagram space.

The second point regarding a shift register works as well, but you're basically having to keep track of all of your events separately from where LabVIEW is keeping track of them. Again, it certainly *works*, but it adds a layer of complexity to the code, and adds a place for a user to make a mistake.

The concept in my head is to have the "Register for Events" function behave like a property node, where you could right click and select Change to Read. As it stands, to overwrite the event sources on that particular Event Registration Refnum, you have to overwrite all of them at once with a single cluster. For a property node with a cluster element, you can do a "Read" on the cluster, use a Bundle by Name to change one element without changing the rest, and do a Write on the whole thing. Alternatively, you can just do a Bundle by Name on the cluster you want to modify, then select Cluster.Element and overwrite just that one thing.

You can't do that here, because you don't have a way to read the present value. If you could *read* the events on the Event Registration Refnum (like a property node) then you could change just one of them.

The issue IMHO is that LabVIEW already knows what events are there, the user just can't read them. A shift register helps with this, but now you're duplicating which events are registered in two different places. My idea is to add a way to read those events so you could inspect them, replace them, generate user events on those channels, and so on.

Hope that helps explain things.

[wiebe@CARYA]

Hope that helps explain things.

It is (and was) clear. Just exploring the idea a bit. Those dynamic events are a lot less flexible then they should and could be, that's for sure. I think I'd use his if it was available. +1.

[BertMcMahan]

Gotcha, thanks for talking it out with me. I was worried when I posted this that I was just misunderstanding how to use the refnum, so I'm glad to see I'm not the only one who would like a bit more functionality with this 🙂

[Intaris]

No. I would fight this idea with my last breath. (Perhaps a slight dramatization).

Processes which expose registered events have their private events exposed willy nilly if one can retrieve the user event from a registration refnum.  This destroys the little encapsulation available with events.

[wiebe@CARYA]

So it should stay completely inflexible (and frankly unworkable)? Not sure if the proposal is the perfect solution, but some flexibility would be nice.

The encapsulation is already violated, because anyone can already get he event registration and close it. Or change it, but it's unpractical.

[BertMcMahan]

@intaris, perhaps a middle ground would be to have a way to only select the events you wish to overwrite? In my proposal I don't actually need access to the user events themselves, I just need to be able to overwrite only the specific one that I need. I figured that reading the whole lot of them would be an easy way to do that, but of course if I had a way to *just* overwrite the one I needed I wouldn't need actual *read* access to the user events. Perhaps a better idea would have just been "Let programmers select single events from within a bundled registration", but that's a bit less concrete of an idea.

[Intaris]

It is already quite easy to replace individual events within a registration refnum. Just wire it into a "register for events" node and wire up only the events you wish to replace. So this proposal is not a middle ground. Its the status quo.

[Intaris]

 @wiebe. It is neither inflexible nor unworkable.

A registration refnum (a subscription) and the event itself (the thing being subscribed to) are two different things with often vadtly different scope and access privileges.

Or do you think that you should be able to cancel everyone's morning paper subscription just because YOU dont want it any more? Becsuse this is essentially what you are proposing.

[wiebe@CARYA]

@Intaris

I'm all for encapsulation. I still think event registration is a pain to work with. Encapsulation is already violated, since the entire event structure is not easy to encapsulate. Callback events help a bit, but are very unstable...

When I say it's a pain, I didn't mean this particular situation, but in general. E.g. clustering registrations is great, until you change it. Then you need to reconfigure the event structure unless you're very lucky. Also, getting the exact event name you want in the event structure can be a puzzle.