Consistent naming of Event Messenger Channel Event Sources

[Bob_Schor]

The Event Messenger Channel, "formally" introduced in LabVIEW 2017 but available as a "Beta" in LabVIEW 2016, provides a useful (if probably under-used) way to provide Channel "Feedback/Input" into a LabVIEW Event Structure.  However, there are some "missing Name pieces" that are inconsistent with the naming of "ordinary" User Events (and an interesting internal inconsistency with those Ordinary User Events that I didn't discover until wrestling with these issues involving the Event Messenger Channel).

This Snippet shows two User Events:

1. A Boolean Control called "Yes" generating an Event Messenger Writer/Reader pair to get the Event Registration Reference for which I created a Constant and gave the Constant the label "OK".
2. A Boolean Control called "Go" for which a User Event and Registration Reference for which I created a Constant and gave the Constant the label "Stop".

The two RefNums are put into a Cluster to allow the two Refnums to be bundled by name and wired to the Event Loop's Dynamic Event Terminal.  Note that the Cluster Names take the names "OK" and "Stop" given to the Refnum Constants used to created the Named Cluster.  [It's much less "interesting" if you use a simple "Bundle" and partially lose the ability to Name That Event].

Event Messenger User Event

When you go to choose the Event for the Event Case, you get the following Event Sources:

Event Sources

Note that the Event Messenger User Event, named OK, with a variable named Go, has no "identifier" in the list of Event Sources, only <channel value>.  Indeed, if there were several Event Messenger Channel Wires bundled together, all given different names, they would all appear in this "Selection" Screen with identical names, but referring (unbeknownst to the Developer) to different Channels.  Note that in the Event Structure, itself, this Event is listed as <OK.channel value>, so it is at least (in the Event Structure) picking up the name the User gave to the Event Reference.

The other User Event Case (for a "normal" User Event), uses both the name used to create the User event (here "Go") and the name used for the Event Registration Refnum (here "Stop"), creating an Event Source named "Go" (the User Event name) and an Event Structure label of <Stop.Go>.  I'd "discovered" (don't remember how I learned this) the trick of putting a Label on a Constant used to Create User Event to "Label" the User Event in the Event Structure, and learned the trick of creating labeled Event Registration Constants and bundling by Name to (partly) create named Event Messenger Cases from the Event Messenger Example files (thanks, AQ or whoever developed these Examples).

Stop/Go Event Case

I'd like to suggest that, at a minimum, <channel value> be replaced with the label, if present, of the variable used to create the Channel Writer.  The quirk whereby an "ordinary" User Event can get two names (as in Stop.Go), one from the Create User Event, the other from generating the Registration Refnum, probably shouldn't be touched lest other code breaks, but it is amusing ...

Bob Schor

[AristosQueue (NI)]

Not possible. The name "channel value" is compiled into the *subVI* and cannot shift with its callers.

An event doesn't have two names. There are two different entities, each of which has it's own name. One is the name of the registration refnum, as named by the local cluster. The other is the name of the event within that registration refnum, as named by the Create User Event node.

 The single event registration refnum can include multiple events. If you were to grow your Register Events node and add additional events for "Dance" and "Sing", you could get "Stop.Go", "Stop.Dance", and "Stop.Sing" in the Event structure. In all cases, the registration refnum has one name and the event has another name. The relationship is similar to nested clusters: Cluster A containing cluster B containing integer C would show A.B.C. The integer "C" doesn't have three names... there's a name path of three separate entities.

The name of the event has to be compiled into the type. That is done at the Create User Event node. Unfortunately, I had to pick one name that would represent the channel firing regardless of the owner of the event. There's no facility within user events for making a subVI able to return different events based on callers. That facility doesn't event exist with malleable VIs (although it is argument number N, where N is getting larger, in favor of doing *something* to malleables to allow name propagation -- no idea what that should look like).

I really don't see any way to make this request possible given which parts have to be compile-time decided. 😞 At best, I could suggest a special node that allows the renaming of events inside an event registration node (which you could actually do today if you were really really crafty about how you built up that Bundle By Name node, but it would take some effort).

[Bob_Schor]

Okay!  Thanks for explaining the complications and distinctions!  Sometimes we make "discoveries" about features that might have been there all along but were never noticed (like the ability for "normal" Events to have a pair of names, one associated with the Event itself, the other with the Registration).

Could it at least be possible to have Event Messenger "names" say <Channel Value>?  I like the poetry of e.e. commings, but find all lower case tedious to read, especially when naming something (I sometimes err on the Other Side, particularly when Trying to Make a Point ...).

Bob "bob" Schor

[AristosQueue (NI)]

LabVIEW has standardized on capital letters for the names of types and lower-case letters for parameters and field elements, except where a proper noun is involved (i.e. "flat plane" vs "Cartesian plane"). The "channel value" is consistent with that standard. (Note that this is a standard that is only about 3 years old, so you'll find plenty of exceptions, but we're adhering to it as much as possible with new development.)

[okubik]

Hey Bob,

you can still hack it with a bit of the coding overhead. You need to put in your cluster prototype which bundles your user events tweaked event prototype. As long as your event data matches LabVIEW takes all the labels from the prototype and injects the event data. So in the edit mode you can work with custom meaningful names while you will obtain the event data during the execution. However this is still dangerous because this sort of typecasting is done unseen behind the scene. Here is my example:

How I did it?

1. I created a cluster constant matching the event data of a boolean event channel. In my case I took the "..\Documents\LabVIEW Data\2018(32-bit)\ExtraVILib\ChannelInstances\Event Messenger-bool\Event Data.ctl" event data prototype (simply by digging deeper and deeper in the VI tree of Channel Event Writer). Then I disconnected it from the TypeDef instance and I changed the label of the cluster to "BLAH" and changed the label of the 1st cluster item from "element" to "Stop Value".

2. I created and registered a user event

3., 4. I created a constant out of the event registration refnum (and after renaming to "AAA" I finally dropped it to the cluster prototype)

Now I can see very well organized User Events in the Edit Events configuration dialog and also the event data doesn't have generic name "element".

Have fun! 🙂

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.