Jump to content

User event datatype propagation


Recommended Posts

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

post-195-1212507274.png?width=400

Link to comment

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 :P. 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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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 :P.

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.

Link to comment

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

Link to comment
  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.