Losing external cell references when dropping copies of a shape

[big_trog]

Running Visio 2003 Pro standalone.

The scenario:
I have a group G that contains shapes A001, B, and C.
Each of these shapes contains cell formulas that
reference custom property values in the parent group.

I've written a macro that drops a specified (by the user)
number of additional copies of A001 into the group (using
the DropMany() method) and sets the names of the new
shapes to A002, A003, etc. So far, so good.

The problem:
The cell formulas for new shapes lose their references to
to the custom properties in the parent group during the drop.

Is there any way to preserve external cell references during
a Drop() or DropMany() operation?

Alternatively, is there any way for a shape sheet to reference
a cell in the shape's parent without knowing a priori what the
name of the parent is? (One can reference page cells as
ThePage!cellName or document cells as TheDoc!cellName;
it'd be great to have a syntax such as TheParent!cellName.)

(The workaround is to have the macro copy the affected
cell formulas into the new shapes. However, this is less
than ideal for two reasons: 1) Performance suffers if the
number of specified copies is large, and 2) I'd prefer that
the macro not have any knowledge of the copied shape's
cell formulas, since I want to reuse this macro for more
than one kind of shape.)

 

[Mark Nelson [MS]]

Yes, wouldn't TheParent!cellName be great? I think so, but Visio does not
support that syntax.

My question is how are you dropping shapes into the group? If I take a
sub-shape in the drawing window and copy it, the copy is initially not part
of the group. Therefore, the group shape references are lost. When the
shape is added to the group, it is too late to restore those references.
However, if I perform the same operation in the group edit window, the copy
is also part of the group and the references are intact.

 

[big_trog]

The operation is being done by a macro on a selected shape
in the drawing window. The code looks something like this:

Public Sub DuplicateSubshape()
Dim group As Visio.shape
Set group = Visio.ActiveWindow.Selection(1)

Dim numNewShapes As Integer
numNewShapes = ... ' Prompt user for number of new subshapes

ReDim shapeArray(1 To numNewShapes) As Variant
ReDim coordinates(1 To 2 * numNewShapes) As Double
' The subshapes are set up to control their own placement within the
' group; therefore, we don't need to initialize the coordinates array.
Dim shapeIDs() As Integer

' The subshape to copy is named A001 and is guaranteed
' to exist in this group.
Set shapeArray(1) = group.Shapes("A001")
numDropped% = group.DropMany(shapeArray, coordinates, shapeIDs)

' Set the names of the new shapes
...
End Sub

As you see, the new shapes are dropped directly into the group.
This works fine except that the subshape cell formulas lose all
their references to cells in the group shape, even if such formulas
were guarded.

What does the DropMany() function do under the hood? Does it
copy the subshape to the clipboard or some other buffer before
dropping the copies? (This might explain why the external cell
references are lost.) Is there any workaround other than writing
additional code to restore the corrupted cell formulas?

Regards,
John B.

P.S. - Consider this an enhancement request to add the
TheParent!cellName syntax to Visio. Are there architectural
reasons why such a syntax can't be implemented, or is it simply
because no one has gotten around to doing it yet?

 

[Mark Nelson [MS]]

I'll have to check with our development team to determine whether DropMany
is discarding the references to the group or whether the Drop methods in
general perform a "cleaning" of the dropped shape before they are instanced.

As for the ParentShape referece, this is something that I've wanted for some
time. Unfortunately there are some complicated technical hurdles here.
This is essentially the difference between early binding and late binding in
software. The shapesheet only does early binding now, and all the formula
dependencies and recalc optimizations are built around this. Enabling late
binding is a lot of work.

--
Mark Nelson
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[big_trog]

Mark - Thanks for checking; I look forward to hearing
what the development team has to say.

I've run into another problem that may be related:

I have a stencil TestStencil.vss. In that stencil's document
sheet, I created user-defined cell rows User.Test1 and
User.Test2. I also created a master shape MyShape with
a shape sheet cell that references one of the document
sheet cells as TheDoc!User.Test1. When I (manually) drop
an instance of MyShape onto a page in a new drawing, the
referenced cell User.Test1 is automatically copied to the
new drawing's document sheet. So far, so good.

However, if I set User.Test1 in the stencil document sheet to
reference another cell in that sheet (say, User.Test2), then
try to drop an instance of MyShape into the new drawing,
the drop fails, and I get an error dialog stating:

"An error (318) occurred during the action Drop On Page.
Referenced cell <some cell> does not exist."

Invariably, the <some cell> in the error message refers to
a cell that never existed in the first place; thus, not only does
an error occur, the error message itself is bogus.

What I WANTED to happen was to have both the directly
referenced document sheet cell and the indirectly referenced
cell copied to the drawing's document sheet. I tried putting
DEPENDSON(TheDoc!User.Test2) in a scratch cell in the
MyShape master, but that didn't help.

This problem occurs in both Visio 2002 and Visio 2003.

Is this another symptom of the early binding behavior you
described? Is there any way for me to set up cross-referenced
document cells in a stencil, then have them imported into the
drawing document when the appropriate shape instance is
dropped? (Yes, I really want to do this.)

Thanks,
John B.

 

[Mark Nelson [MS]]

Wow. I just had this error pop up on me today, and I don't think I've ever
encountered it before. What a coincidence. In my case I was trying to
paste a calendar shape into a blank drawing page (using Visio 2003). I'll
add your scenario to the bug report and see if having two different examples
helps identify the problem.

--
Mark Nelson
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark Nelson [MS]]

After some digging, I found an old discussion of this problem in our bug
database. There is a specific issue with the User-Defined section of the
Document Shapesheet not bringing over all the necessary references.
Unfortunately, this was an intentional design decision, so changing the
functionality is not very easy. I have asked our development team to review
the design decision for the next version of Visio.

In the meantime, you will have to look for workarounds here. If you know
what the dependent cells are in the Document Shapesheet, you could write a
routine to copy them for you. You could also just copy all the User-Defined
rows from one document to another.

--
Mark Nelson
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.