Decorations outside cluster - part of cluster or not?

[CoastalMaineBird]

LabVIEW 8.6.1.f1

If I have a cluster on a panel, and I have a decoration (a flat frame, for example) behind it, then if I hide the cluster, the whole frame appears.

That's just what I would expect.

If I build a cluster in the CONTROL EDITOR, and put a flat frame outside of, and behind, the cluster, and call it a TYPEDEF, then when I put an instance on the panel, and hide the cluster, I see no frame.  It's just not there.

Why?

The DECOS[ ] property of the cluster won't help - it's not part of the cluster.  But if it's not part of the cluster, why does it get hidden with it? 

Message Edited by CoastalMaineBird on 07-21-2009 12:58 PM

[nathand]

When you use the type definition, the frame is part of the control, so when you hide the control the frame disappears as well.  I assume you don't have any way to hide the cluster other than using a property node that refers to the entire control.  No idea how you could get the behavior you seem to want, though.

[CoastalMaineBird]

so when you hide the control the frame disappears as well.

That's what is surprising to me.  It's not WITHIN the cluster, therefore it's not CONTAINED by the cluster, but apparently it's still OWNED by the cluster.

I've already moved on, I made a parent cluster with all those frames in the same places as the frames that are in the cluster. Now I can hide the cluster and leave the empty box showing, which is what I need to do.  I don't even need the frame inside the cluster, except to line things up.

Let's hope I don't have to change the sizes - the frame inside is part of the typedef, but the backing frames are 32 separate decorations. 

[nathand · Accepted solution]

---

CoastalMaineBird wrote:

so when you hide the control the frame disappears as well.

That's what is surprising to me.  It's not WITHIN the cluster, therefore it's not CONTAINED by the cluster, but apparently it's still OWNED by the cluster.

---

It has nothing to do with the cluster; it's an issue of the custom control, of which the frame is a part.  You could do the same thing with a big square boolean and a frame behind it.  To me, it wouldn't make any sense if it didn't work this way - wouldn't it be odd if you created a custom control with some decorations, then used a property node to hide the custom control but only some of it vanished?

[CoastalMaineBird]

wouldn't it be odd if you created a custom control with some decorations, then used a property node to hide the custom control but only some of it vanished?

Yeah, I guess you're right.  But I've always associated a container with ONLY the things it actually CONTAINS, so therefore hiding a cluster would only hide the things inside it.

That's obviously the wrong way to look at it.

A reference to a TYPEDEF'ed control is a reference to the whole thing. If I disconnected the cluster from the typedef, then it has to revert to my expected behaviot.

Thanks for your thoughts! 

[nathand]

---

CoastalMaineBird wrote:

A reference to a TYPEDEF'ed control is a reference to the whole thing. If I disconnected the cluster from the typedef, then it has to revert to my expected behavior.

---

You're still not quite there.  Disconnecting the typedef won't give you the behavior you expect either because you'll still have a custom control, it just won't be linked to any master definition.  You'll get the equivalent of having selected "control" rather than "type definition" in the control editor, and the decoration will still be part of that control.

[CoastalMaineBird]

OK, tests show you are exactly correct.  It's a bit surprising, but it does make sense when I slow down to think about it.

A reference to the thing can be treated as a reference to a cluster (since a cluster is the main container), but it's also a reference to the control as a whole.

There is apparently no way to get a reference to the decoration that's outside of the cluster - in my test, the decos[ ] property returns an empty array, even though a decoration is part of the control. 

[nathand]

---

CoastalMaineBird wrote:

A reference to the thing can be treated as a reference to a cluster (since a cluster is the main container), but it's also a reference to the control as a whole.

---

Not to drag this out more than necessary, but it will make a lot more sense if you stop worrying about the cluster in this situation.  You'd see the same thing with a boolean or a numeric or any other data type instead.  The cluster isn't "the main container," it's just the part of the control that defines its data type.

[CoastalMaineBird]

 You'd see the same thing with a boolean or a numeric or any other data type instead. 

True, but since I encountered the problem while dealing with a cluster (container), the "container" characteristics led me down the wrong path. 

A custom control must have one and only one control/indicator to define a basic data type.

Decorations are attached to it, but not necessarily contained by it.

Once defined in the control editor, the thing is a whole unit, decorations and all.

If you can get references to pieces of it (decorations included), then you can deal with them separately (if it's not a STRICT typedef).

You cannot get references to decorations outside a container.

I think that about covers the rules. 

Thanks, Nathan