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.

[Intaris]

 Wiebe, I agree events can be a PITA but the proposed idea for me is in the wrong direction.

I have 99 problems with user events but this isnt one of them.

[wiebe@CARYA]

Can't say I had this exact problem either. But I can see how it's annoying when you encounter it. The encapsulation is a strong reason against it, but encapsulation is an acquired taste!

[BertMcMahan]

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

I don't think we're on the same page, but perhaps I'm mistaken. You cannot replace individual user events that were bundled prior to the Register for Events function- you can only replace the entire bundle at a time. That's the core issue I'd like to solve. As it stands, you have to maintain a separate list of your registered events somewhere else, and make sure you rewrite the bundle with only the specific elements that need to be replaced. In the original post, you cannot simply overwrite/re-register Event A or Event B; you MUST overwrite both of them at once. If you bundle the event registration refnums (NOT the user events themselves) then you can replace them individually.

In the example above: the first version bundles the User Events into a single cluster *before* registering them. This is useful when a subVI is creating a bunch of user events, but I don't want them to be registered yet, just generated (like in the QMH template). I'd like to be able to register the events in the same code block as the event structure, as it seems to play better with names this way.

I could register for Events A and B with separate Register for Events functions (like in the second example) but this is very inflexible if you ever need to add events.

The third example shows what you have to do to maintain your event history- you must use a shift register or local variable to maintain your event registration history, which is 1) a pain to do, 2) introduces lots of room for accidents while coding since it requires ALL other event cases to pass the wire without acting on it, and 3) duplicates your data everywhere.

I hope that's a bit more clear. I don't think my proposal is the ONLY way to do it, but it's A way to do it. A much better way (if it was possible?) would be to let me use the first example, but let me pick a specific User Event when I wire in the registration refnum. Right now I can only pick that cluster.

Please let me know if I'm doing something the wrong way or if I'm just coding poorly here. My original goal is to have a producing loop running in one place, publishing some information to a few designated User Event channels. I'd like to be able to subscribe and unsubscribe from those channels arbitrarily. If this is just a fundamentally wrong way to do that, I'd love to hear it from someone more experienced than I am!

[AristosQueue (NI)]

I agree with Intaris. This is, to me, a bad idea. I'm not going to propose closing it yet to leave it open for more  brainstorming, but it's got an uphill fight in my book.

[BertMcMahan]

After hearing you guys out I can understand the reasoning behind saying No to the original request. I got a bit ahead of myself trying to come up with a solution to a slightly different problem- I don't actually need access to the individual elements, I just need a way to *overwrite* individual elements.

AQ, did you take a look at the snippet I posted just above your last comment? It seems to me that there should be a way to write the registration with a new queue without having to maintain a duplicate shift register. Having to have a shift register seems to invite issues where either the SR or the registration gets updated, but not both (due to coding accidents). This would be a tricky bug to track down.

IMHO it seems to be an inconsistent operation in that User Event refs can be overwritten individually if bundled *after* a Register For Events, but *not* if they're bundled *before* the Register For Events.

At any rate, I'm fine with closing this idea as it only "band-aids" the issue I was originally seeing. It doesn't address the root cause- which is that I need individual write access to a registration refnum, not read access to a queue.

[AristosQueue (NI)]

Bert: No, I skipped that part of the discussion... looking at it now...

Hm... looking at your diagram, I can see the issue. I'll flag this discussion to the dev who created events, see if he has any commentary.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

[BertMcMahan]

I kinda forgot about this idea, but AQ, any chance you were able to get some info from the guy who created the events? Just curious.

[AristosQueue (NI)]

Bert:

It would be possible to build, but wasn't just a dead-easy thing to do, and with the low kudos, there's no plans to do it.

-- Stephen

[BertMcMahan]

Gotcha, thanks for the update!