Events Registry "Unbundle" Node

[smmarlow]

Currently, there is no access to the User Event references in the Dynamic Events Registry reference.  If you have a lot of user events, you either have to bundle the references together into a cluster, or have many wires through the program.  My proposal is to add a "Registered User Events" node that allows the programmer to "unbundle" the registered user events references.

Also, the Register for Events node should change the User Event label to the user event name when a user event is wired to it.  Finally, there should be some mechanism to access/control the event queue programmatically, perhaps an "invoke node" coupled with the ability to create a reference to an event structure.  This invoke node would allow the user to flush the event queue, or perform other operations on it, etc.

[JackDunaway]

>> My proposal is to add a "Registered User Events" node that allows the programmer to "unbundle" the registered user events references.

Here's an Idea that is actually the opposite of what you're proposing: Don't expose the Refnum to a pre-registered User Event within the Event Structure. In that Idea, I make a comment that I am against the Idea, instead gunning for what you're asking for in this Idea - easier access to the references that have been registered inside an Event Registration Refnum (keep in mind, you can register not only User Event Refs, but also Control Refs and VI Refs).

I won't disagree with this Idea or retract that comment, but I've become more ambivalent toward the notion of exposing registered references, the main reason being labor involved with tracking down the properties and methods invoked upon a reference. Frameworks that wrap the messaging resource are easier to debug and track rogue message behavior.

>> there should be some mechanism to access/control the event queue programmatically

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-discard-stale-entries-in-the-event-queue/idi...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-an-event-terminal-for-event-queue-size/idi-p/1...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Expand-Event-structure-functionality-priority-for-even...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Expand-Event-structure-functionality-control-of-event-...

[Intaris]

My other idea "Dont' expose..." is not actually quite the opposite of this.

My comment on the ability to prevent the refnum being exposed being toggled via switch when creating the event refnum would allow for my idea and this one to both be implemented.  The exposure of refnums would then only work (in whichever method possible) for events who have not been told to keep the refnum private.

[smmarlow]

Sorry to all users for my lousy post with images as attachments.  First post here on NI forums and my 47 yo eyesdidn't see the insert image button.  Anyway, Jack I share your concern about the exposed refnum in the event structure, but at least you can shrink the node so it is not exposed.  I really don't see the problem there.  If you think the exposed ref is dangerous, then just don't expose the terminal.  But I do think the user should have access to the wrapped user event refs.  I'm on the fence about other types of refs that are registered (controls, VI's, etc.), as they often change during execution which could cause unexpected behavior in programs that perfom operations on the hypothetically "unbundled" references.

Current

Proposed

[Intaris]

Just saying "don't expose the terminal" for the event structure in view of preventing event subscribers from destroying a shared event is kind of silly.  Anyone can expose it and do whatever they want with the event refnum.

But I digress....

[JackDunaway]

>> My other idea "Dont' expose..." is not actually quite the opposite of this.

Yeah, they're not perfect opposites or mutually exclusive, but I thought that it was worth pointing out that this Idea is fundamentally "make it easier to access bundled/registered event refs" and your Idea is fundamentally "make it harder to access bundled/registered event refs".

(In my mind, I keep placing a Property Node where you have diagrammed the "Read" Register node, which would provide access to information about the status of the queues, or replace it with an Invoke Node that would perform actions on the Event Queue, but this is another topic altogether)

[Intaris]

I find this idea appealing for the occasions where I don't want to hide the actual event refnum.  I would still like the OPTION to hide the refnum though because there are software architectures which can be brought crashing down quickly by exposing this essentially private data element.

[Darren]

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