Allow Dynamically Registered User Events to preserve Native Datatype in Event Structure

[JackDunaway]

The current behavior of LabVIEW is as such:

The pick list of event data strips the cluster, only allowing access to the elements inside the cluster. In order to manipulate the native datatype, you must reconstitute the cluster inside the event structure, a performance hit on large data structures firing at quick event rates. This is not to mention a messy FP.

I suggest that User Events preserve the clustered event datatype, allowing the programmer to access to the native datatype on the consumer end. The option to select only the element "Clustered Typedef.Array of I32s" of course still remains, but is not forced upon you. (Note that the below block diagram is NOT a direct LabVIEW screenshot... brought to you by trickery and a paint program. I clustered the cluster on event datatype [not shown] so that the event structure could eat the outer layer)

My motivation with this suggestion is directly linked with my other post on the Big Typedef Issue.

[andre.buurman@carya]

The same principle could also be done for "key down" to easily distribute the event elements to another handler. E.g. for use in Xcontrols.

[Matthew_Kelton]

All you have to do is put your typedef in a cluster (i.e. nest your Clustered Typedef constant inside another cluster).  Then you will have exactly what you want.

[RavensFan]

Yes, but then you have to modify all your other code that uses this cluster/typedef to be a cluster/cluster/elements to handle the extra layer of the cluster which is just a hack.  There is no logical reason for the event structure to strip away a layer of the cluster.  At best, it is an undesired behavior, I worst, I would consider it a bug.

[JackDunaway]

Matthew,

I'll quote myself from above: "Note that the below block diagram is NOT a direct LabVIEW screenshot... brought to you by trickery and a paint program. I clustered the cluster on event datatype [not shown] so that the event structure could eat the outer layer"

I'll have to agree with Ravens that this is hacky. It's a solution, yes, but I think that default behavior should NOT eat the outer cluster. Ravens described my sentiments exactly: "At best, it is an undesired behavior, at worst, I would consider it a bug."

Regards,

Jack

Message Edited by JackDunaway (mechelecengr) on 09-09-2009 08:13 AM

[Matthew_Kelton]

The issue is that if this is changed to Jack's desired method, then I can't have multiple base items in the event menu.  Everything is required to be clustered together in the selection of items.

I use the user events in both ways Jack showed above.  Usually though, I have multiple items besides just the cluster.

Sometimes the data in the events doesn't necessarily need to be processed together.  I actually tend to use your first example quite often (not rebundling the data, though), and like it.  Your prosped method would mean that all user data events only result in one top layer item, and users that use the current functionailty will complain.

For example, if I have a simple user event that is just a single item (number, boolean).  I now have an extra layer I don't want.  People will ask why they need to navigate a cluster to get to a boolean.  The old way was so much better.

Unless there is a boolean option to make it selectable, NI will not make everyone happy.

[JackDunaway]

Matthew: Remember, even with the current implementation for FP object events, you can select components of a cluster using dot notation! My logic is undeniable, you know you want to Kudos this infallible idea.

If this behavior does not fully suit your need due to space constraints (understandable), create a new idea that allows "Hide Full Names" on event structures, just like cluster Unbundle/Bundle By Name. I would Kudos that idea!

Message Edited by JackDunaway (mechelecengr) on 10-13-2009 07:34 PM

[DavidBoyd]

I questioned this very behavior some time ago, suggesting that it seemed syntactically inconsistent. I seem to recall that AQ replied with an explanation that it WAS consistent with the overall event structure approach, where an event case which handles multiple event types will return the common elements (i.e., intersection of cluster element names) for the event data.

That being said, I would still like to see the overall structure as an option for the event data.  Kudos (a little late).

Dave

[JackDunaway]

>> I seem to recall that AQ replied with an explanation that it WAS consistent with the overall event structure approach, where an event case which handles multiple event types will return the common elements (i.e., intersection of cluster element names) for the event data.

Interesting, I've never realized that advantage.

That means, that instead of the interface I suggested (where you drill down from the top level cluster), maybe it's better to simply add one additional Event Data Node that is the fully preserved (i.e., not fanned-out) data structure.

With an additional Event Data Node, if you have two different types of events handled by the same event case, you'll still get the intersection of the common data elements like you do today, but the two top-level non-fanned-out data clusters would be excluded from the intersection.

[JackDunaway]

The "opposite" of this Idea is posted here: Expand Data Interface to Built-In Messaging Primitives

[jyang72211]

I just ran into this problem today.  I want my cluster in one piece!!!!!