Like it or not, including the path is the nature of the way Excel embeds
the links to VBA add-ins. It gets worse: Excel uses the drive letter
path, VBA uses the UNC path. In my experience too, links to .xll files
are not plagued by this.

Why is the shared drive sometimes unavailable to you? If you mean that
you want to work from a PC that is not connected to the network, you can
always use the DOS SUBST command to mimic the .xla's path on a virtual
drive. That would solve the problem for functions called from a worksheet.

Jerry

Bura Tino wrote:

Hi,

This is the same issue as posted before, but this time I will start in a
different place.

There seems to be fundamental problems with using functions from a vba
project. If user A and user B both have the same vba add-in installed (but
in different paths), and user A builds a worksheet which uses a function
from the add-in, he cannot send this worksheet to user B. This is because
Excel will look for the add-in to be installed in the same place and won't
find it there. This clearly defies logic, but I won't get into that.

Charles Williams proposed two solutions:

- always install the addin in the same place (use an install package to make
sure)
- change links in the workbook (either manually or make your addin check
each workbook that is opened for links to itself and change them to itself)

Solution 1 is unacceptable because it is good practice to put add-ins on the
a shared drive so they can be upgraded invisibly to the users. At the same
time, to me as the developer, the shared drive is not always available.
Solution 2 is acceptable, but c'mon!

A third solution that I will pursue if I get no suggestions is to rewrite
the add-in in C++, since C++ add-ins seem to be free of this ridiculous
problem.

Does anyone have any suggestions?

Bura

PS: Perhaps I could go with the first solution proposed by Charles if (in
abcense of a network) I could fake having an F: drive by mounting one of the
local directories. Does anyone one if this is possible? Sorry for the OT.