A node to return the datatype of a user event refnum

[DavidBoyd]

Presently, to build a cluster wire to send to a 'Generate User Event', I need a constant as a wire source, or perhaps a (hopefully typdef'd) control. I would find it very handy to be able to recover a wire source of the datatype of a user event refnum, carrying default data.  (This wire would always reflect the datatype of the refnum, making type propagation that much easier.)

[AristosQueue (NI)]

Please post a screenshot showing code where such a node would be used.

[DavidBoyd]

Stephen,

Sorry, I post here so infrequently that my screenshot-posting skills are pretty meager.  Let's see if this works:

An example of the existing method:

and the new method would look like:

I wouldn't think this new node would 'do' anything at runtime - this just creates a wire holding default values.  I realize I need a typing wire for the 'Create User Event' node in the first place, but wouldn't this allow me to avoid revisiting code for type changes in some use cases?

Dave

[JackDunaway]

I've had an Idea brewing for a while (Expand Data Interface for Built-In Messaging Primitives) that took shape after this Idea was posted. I think it fixes the issue you're trying to resolve, packaged into even less syntax.

[JackDunaway]

Here's exactly what I'm talking about, illustrated below. Notice it's a little bit smaller? :smiley-wink:

[tst]

David, a more general implementation which should cover your use case has already been suggested (and implemented in 2010) - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/View-Cluster-Constant-as-Icon/idi-p/1011239

[DavidBoyd]

Tst,

I'm aware of the cluster-as-BD-stub option (I'd read that idea a long time ago and I hope I kudoed it too).  I'd still like to see my idea here implemented, since adding a cluster constant to the BD (shrunk or not) only 'works' in this example if it's typedef'd.  Frequently this means I have to type-define a cluster that itself is just a collection of other type-defined clusters.  Seems like having a wire that is guaranteed to reflect the current definition of the event data, would be preferable.  I use this approach for queues and notifiers by using their peek or status nodes. Why not user events?

Dave

[AristosQueue (NI)]

The "cluster as icon" solution doesn't fix anything.

As for the choice between the "easier bundling" that Jack proposed or the "extract the cluster type" that David proposed, I can see use cases for both. I'd be inclined to give priority to David's solution because it provides a partial solution for Jack's. Jack's becomes syntactic sugar if we have David's node, and David's node can be used to solve other data handling situations where I'm trying to bundle in values of the cluster and not immediately sending it to the event, or if I want to wire to an Unbundle node. Jack's solution also has issues in that it does a "bundle by index", where as I would want a node that does "bundle by name", generally a much safer mechanism because it generally keeps up to date as code changes (in fact, it always works as long as you're careful to always have unique names in your cluster, which most people appear to do, whereas "bundle by index" can get confused).

I'm going to kudos this idea and repost this same comment in Jack's idea -- perhaps someone in that thread can suggest improvements regarding the use of element names.

[tst]

> The "cluster as icon" solution doesn't fix anything.

Why not?

This request obviously only applies to clusters, which should generally be typedefs. I would argue that David should probably make his big cluster a typedef as well, although I can see why he doesn't want to.

I should also point out that one excellent reason for making it a typedef is that in his example he's using the event reference as an input to a subVI. If the event data type isn't a typedef, making any kind of change to it (adding another cluster or renaming one of the clusters) would break all the event references. It's possible that it would break even if one of the internal typedefs changed, but I assume that's not the case.

I also agree that the mini-cluster solution isn't ideal, but it certainly seems to have merit.

[Darren]

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

[DavidBoyd]

But... but...

It got discussion and a kudos from AQ!  Surely that's like a get-out-of-jail card, or a Daily Double, or a winning lottery ticket, or...