Problem with VBA References when installing VSS, VST

[Peter Dewildt]

I have an application I have developed in Visio over the past few months,
starting with Visio 2002 and now 2003. Basically it uses information from a
drawing to update a database.

I have the shapes and a lot of VBA code in a VSS file, and the drawing in a
VSD. The VSD contains a VBA reference to the VSS.

In the past I have been able to copy the two files onto other computers, and
the VBA reference from the VSD to the VSS always worked regardless of where
I put the two files (though always in the same directory).

Now I am ready to put the application into production. I have stripped back
the VSD to an empty page and renamed it to VST.

Everything works find on my computer. However when I copy the VSS and VST to
another computer and create a new drawing based on the VST, and try to
execute any of my code, I get a compile error because the VBA reference is
broken.

The same thing happens if I do what I did before - copy VSS and VSD.

Does anyone know a way around this? It is going to pay painful to tell users
to manually correct the VBA reference.

About the best I can think of is that I have to tell our users that they
will have to put the VSS in a directory with exactly the same name as on my
computer.

I know that Access looks for broken references in the same directory as the
Access mdb. Also in Access I can programmatically set VBA References (using
Application.References) but I can't find anything similar with VBA.

 

[Peter Dewildt]

Some more information:

- if I start a new document from within Visio based on the VST (in my
Templates path), it does not resolve the reference

- if I double click on the VST (or VSD) file, I have no problem - it
resolves the VBA reference to the same folder as the VST/D file

- if I double click the VST, close the document and in the same Visio
session, start a new document based on the VST, it also works.

 

[Mark Nelson [MS]]

I'm not sure what the expected behavior is supposed to be here. I can say
that this is not a recommended method of developing a solution. You might
check into putting your code into a COM Add-in such that you don't pass VBA
around with any of your documents (or stencils). This will be easier to
deploy in security conscious workplaces.

 

[Peter Dewildt]

I have converted it to a COM Add-in as well as to VB .NET.

Works real good.

Peter


(remove "xxx" from email address to contact)

 

[Mark Nelson [MS]]

Good news. I know that required some extra work, but the result should be
much easier to manage over time.

--
Mark Nelson
Microsoft Corporation

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