Shapesheet ParentSheet and ChildSheet keywords

[gwideman]

For development, customization and maintenance of even modestly complex grouped shapes, there is a feature that would ease the task immensely while requiring no actual new ShapeSheet functionality.

This is a set of keywords to stand for common cross-sheet references that currently require using specific SheetIds of the referenced other Shapes.

1. The canonical example is Parent.  Currently, for a child shape whose width depends on its parent:

  Width = Sheet.23!Width*0.5

which would be replaced by

  Width = ParentSheet!Width*0.5

2. Similarly, references to child shapes could use a keyword like ChildSheet to refer to the children's namespace, like:

User.CaptionBoxWidth = ChildSheet!CaptionBox!Width

(where CaptionBox is the Name of a child shape).

These two additions would hugely clarify shapesheets of complex shapes.

Further embellishments would be useful:

3. Chaining:

--  ParentSheet!ParentSheet!Width 
-- ChildSheet!AChild!ChildSheet!AGrandchild

4. Ability to refer to peer (child) shapes as NextSheet or PrevSheet, as in:

PinX = PrevSheet!PinX + 1.0 in

(In this case, NextSheet and PrevSheet perhaps shouldn't be the default way that these Sheet ids are displayed, but rather optional according to what the shape developed typed in, thus reflecting the developer's intent.  Under the covers that might mean that NextSheet and PrevSheet are actually functions.)

Again these embellishments introduce no significant new ShapeSheet functionality, just improved syntax that would greatly clarify shape behavior.

-- Graham

[Paul Herber]

+1

[wapperdude]

Makes a certain amount of sense, but I think there may be a couple of complications.

1)  Referring to a child.  There are often multiple children at same level, i.e., siblings.  Would need a method to identify which particular sibling.  As you traverse down, the subsequent number of subshapes could (not practically, though) grow at an exponential rate.

2)  Chaining.  Moving down would progress child to child (grandchild? greatgrandchild, etc.) 
      a.)  This would always be relative?  So, if I'm at the 3rd sub-level, say,a grandchild, at that level, the next one down would be its child, but to the upper most family member, it would be a greatgrandchild.
      b.)  Likewise, moving up would also be relative, no pun intended.  Parent, grandparent, etc., but it's always from the perspective of the present location, or is it based upon an "absolute, external view"?

Seems like it could get just as confusing to try and keep track of where you are in the chain and to whom you want to point.

Perhaps an adaptation of a tree view, within or linked to the shapesheet, so you could point and click to get the shape reference?  Hmmmm.  That would be considerable development.  But it could give you an instant visual...
Wapperdude

[gwideman]

Hi waperdude,

On you q1, regarding which child is to be referenced:  I perhaps wasn't clear enough.

In the case of a child referring to the parent, there can be only one (direct) parent, so the single keyword ParentSheet would perform that function.

For a parent referring to a child, as you point out there can of course be multiple (direct) children, so the keyword itself can't refer to any one in particular.

Instead, we'd like to be able to use the developer-assigned name of the child shape (ie: Shape.Name, as automation would see it), instead of the Id-based name (automation: Shape.NamedId, "Sheet.27").  But currently a shapesheet can't reference the namespace of its Shapes collection because that collection has a separate namespace, which is necessitated by the fact that those names might conflict with names in the Shape's own peer-level namespace

So the keyword I suggested, ChildSheet, is a prefix to explicitly specify a reference to the Shape.Shapes' namespace.  Supposing we have a FancyAssembly group shape which has a child shape called "FrontSubunit", which happens to have id 43 on the drawing, and thus has NameId Sheet.43.  Currently, a formula in the group's Shapesheet has to use Sheet.43!Width to reference the FrontSubunit's width cell.  I propose use of the keyword to allow using ChildSheet.FrontSubunit!Width.

I actually think "ParentSheet" and "ChildSheet" are names that are too long (better would be just Parent and Child), but I'm spelling them out here to be explicit as to their function.

I also point out that this naming scheme eliminates the problem that at present the cross-level references appear different in every instance of the composite shape, leading to complete obfuscation when you try to inspect a particular one.  Ie: In the first instance of our FancyAssembly shape, the FrontSubunit might appear as Sheet.43, but in a second FancyAssembly it will have a different Id, so appear as Sheet.127, for example.

-- Graham

[wapperdude]

Hi Graham --

Thanks for the clarification.  I better understand your proposal.

Have a great weekend.

Wapperdude