User event datatype propagation

[David Boyd]

Just curious if anyone else sees this the same way I do...

If I create a user event for a simple scalar datatype (which I probably never do anyway), the event data is of course returned as the scalar value, with the data name label intact. But, when I use a cluster as the datatype, LabVIEW discards the cluster label and returns the elements of the cluster as individual items in the event data. I have no option to get the entire unbundled cluster within the event case. The workaround is to add an 'extra' cluster frame around my original cluster, and of course, name-label the outer cluster frame. Does this seem syntactically inconsistent to anyone? Is there a compelling reason for the way it's implemented?

Dave

[LAVA 1.0 Content]

QUOTE (David Boyd @ Jun 3 2008, 11:37 AM)

Just curious if anyone else sees this the same way I do...

If I create a user event for a simple scalar datatype (which I probably never do anyway), the event data is of course returned as the scalar value, with the data name label intact. But, when I use a cluster as the datatype, LabVIEW discards the cluster label and returns the elements of the cluster as individual items in the event data. I have no option to get the entire unbundled cluster within the event case. The workaround is to add an 'extra' cluster frame around my original cluster, and of course, name-label the outer cluster frame. Does this seem syntactically inconsistent to anyone? Is there a compelling reason for the way it's implemented?

Dave

http://lavag.org/old_files/monthly_06_2008/post-195-1212507274.png' target="_blank">

Now that you mention it, yes there does seem to be two sets of rules applied. If we say that this is a bug and you should be able to select the cluster, then that would let us potential poke at the invisable container used in the sclar example. I wonder what I'm missing.

Ben

[Michael Aivaliotis]

A bundle can give this for you. I know you don't want this but hey.

[Justin Goeres]

QUOTE (neB @ Jun 3 2008, 08:44 AM)

Now that you mention it, yes there does seem to be two sets of rules applied. If we say that this is a bug and you should be able to select the cluster, then that would let us potential poke at the invisable container used in the sclar example. I wonder what I'm missing.

That's an interesting way of looking at it. I don't look at the event data terminals as coming from some invisible container; to me they're just terminals that semantically kind of look like an unbundle . But nonetheless, I feel like if I create an event with a cluster datatype, I should be able to get the cluster as a whole at a single terminal in the event structure. It's particularly annoying when the event data is an Error Cluster to begin with.

[David Boyd]

QUOTE (Michael_Aivaliotis @ Jun 3 2008, 12:27 PM)

A bundle can give this for you. I know you don't want this but hey.

Michael,

Does that not give you a broken run arrow? When I just add an unnamed bundler LV complains:

The input data type is unnamed or has cluster fields with no names or duplicate names. You must wire a data type with unique names for each element, since Create User Event uses the type name of the input to name both the user event and data the event carries. These names are visible downstream when a user event is handled by an Event Structure.

I end up having to either 1) use a named bundler, which implies a source-typing wire from somewhere, or 2) modify the original control (generally a typedef instance) to include the extra, named cluster frame. All in all, not a big hassle, but hey.

Dave

[Aristos Queue]

I agree it seems like an odd choice on our part. Having said that, I can't resist pointing out that if you stop using clusters and start using LVClasses, you'll get a coherent data type. :-)

[LATER] Ok. After a bit of thinking, I can explain why this was done, I think. By having LV automatically unbundle the top-level cluster elements, you have the ability to have items at the top level of your event handler, so you can have common elements between disjoint user events. In other words, I can have user event Alpha with cluster "A (numeric), B (double), C (path)" and user event Beta with cluster "A (numeric), D (boolean)". If I ever have a single frame of an event structure that handles both events, the left hand event data node will show only the elements that are in common. If we treated clusters as single elements, you'd have nothing in common between the two user events. But because we unfold top-level items, you'd end up with "A (numeric)" being available in the event case.

[ragglefrock]

QUOTE (Aristos Queue @ Jun 3 2008, 01:28 PM)

I agree it seems like an odd choice on our part. Having said that, I can't resist pointing out that if you stop using clusters and start using LVClasses, you'll get a coherent data type. :-)

[LATER] Ok. After a bit of thinking, I can explain why this was done, I think. By having LV automatically unbundle the top-level cluster elements, you have the ability to have items at the top level of your event handler, so you can have common elements between disjoint user events. In other words, I can have user event Alpha with cluster "A (numeric), B (double), C (path)" and user event Beta with cluster "A (numeric), D (boolean)". If I ever have a single frame of an event structure that handles both events, the left hand event data node will show only the elements that are in common. If we treated clusters as single elements, you'd have nothing in common between the two user events. But because we unfold top-level items, you'd end up with "A (numeric)" being available in the event case.

And to add to this statement, having a cluster of elements is a common way to mask a real (non-user) event. For instance, if a UI event like Mouse Over returns data for Coordinates and the Panel Ref, then I can create a User Event with these two data elements in a cluster and register it in the same case as the real UI event. This lets me fire UI event code programmatically. Not sure this justifies the disjoint behavior, but it's another tool with event programming.

[Justin Goeres]

QUOTE (Aristos Queue @ Jun 3 2008, 11:28 AM)

I agree it seems like an odd choice on our part. Having said that, I can't resist pointing out that if you stop using clusters and start using LVClasses, you'll get a coherent data type. :-)

I actually thought that while I was writing my earlier reply .

QUOTE

[LATER]

Ok. After a bit of thinking, I can explain why this was done, I think. By having

LV

automatically unbundle the top-level cluster elements, you have the ability to have items at the top level of your event handler, so you can have common elements between disjoint user events. In other words, I can have user event Alpha with cluster "A (numeric), B (double), C (path)" and user event Beta with cluster "A (numeric), D (boolean)". If I ever have a single frame of an event structure that handles both events, the left hand event data node will show only the elements that are in common. If we treated clusters as single elements, you'd have nothing in common between the two user events. But because we unfold top-level items, you'd end up with "A (numeric)" being available in the event case.

That's interesting, although in practice I've never wanted to do that (maybe because it never occurred to me that I could?). I still reserve my Error Cluster peeve, though.

[David Boyd]

Thanks, AQ. That makes perfect sense - the use case of overlap of common data elements from distinct events, that is. I still wish there were an option to get the entire user event data in the "original" wiretype, though, for convenience sake.

Dave

[Aristos Queue]

QUOTE (David Boyd @ Jun 3 2008, 10:03 PM)

Thanks, AQ. That makes perfect sense - the use case of overlap of common data elements from distinct events, that is. I still wish there were an option to get the entire user event data in the "original" wiretype, though, for convenience sake.

Use the NI Product Suggestion Center and recommend this as an option.

http://digital.ni.com/applications/psc.nsf/default?OpenForm

[crelf]

QUOTE (Aristos Queue @ Jun 3 2008, 02:28 PM)

I agree it seems like an odd choice on our part. Having said that, I can't resist pointing out that if you stop using clusters and start using LVClasses, you'll get a coherent data type.

I know I'm chiming in late on this, but we found the same issue here (we pass a bunch of data between asynchronos nodes), so we created a current value table that is based on a variant (the tags and their values are variant attributes, which are also varinats). A few hours later, we had a new reuse package that has polymorphic reads and writes so it becomes a virtual data bus. Then, even before reading this thread, we created a new version where that variant data is wrapped in a LVClass. The two methods work great :thumbup:

http://lavag.org/old_files/monthly_06_2008/post-181-1214489256.gif' target="_blank">