How to stop Excel storing the absolute path to an

问题:

I have an XLA file that is to be deployed to a number of users in the organisation as an Excel add-in. My intention is to deploy it to a directory in the user's "documents and settings" folder in "Application Data\MyCompany". (In fact this is all working through a wrapper that copies the latest version of the XLA locally and installs it as an Excel add-in).

However, if a user creates a sheet that references a function defined in this XLA then Excel appears to store the absolute path of the XLA in the function call. Thus, if the user sends the sheet to a colleague Excel fails to resolve the function as their copy of the XLA resides at a different absolute path (as their username is part of the absolute path).

My belief up until now was the Excel "just coped" with this as long as the XLA was installed as an add-in but this does not appear to be the case.

Is it really the case that I need to enforce an identical absolute path for my add-in for all users? This is possible within a single organisation but I honestly can't believe this is true as it seriously impedes sharing of XLS files.

Thanks.

回答1:

There's no good way to do this. I put my xla files on a network share rather than locally and install them via the UNC path. That only works for me because everyone has access to the share, which may not be the case for you. Here's some other alternatives

http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/

回答2:

I simply remove the path with a sub like this one:

Sub RemoveXlaPath()
'
' Goal: delete the path reference to the add-in, i.e. everything before and including the '!'
' ='C:\Program Files (x86)\Microsoft Office\Office14\LIBRARY\populator.xlam'!famedata(...)
'
    Cells.Replace What:="'C:\*xla*'!", Replacement:="", _
                    LookAt:=xlPart, SearchOrder:=xlByRows, MatchCase:=False, _
                    SearchFormat:=False, ReplaceFormat:=False
End Sub

回答3:

Can you specify an environment variable-based path? E.g. %APPDATA%\MyCompany

回答4:

What I have done is if I give a user a XLS , it has in its on open event some code which - installs the the XLA as part of its on open event. It also uninstalls old version if any (delete and command bars). This self distributes. In theory it could clean up any paths. This assumes there is some shared drive which everyone can access, this prevents them copying the XLA to local drive. Alternatively email them a shortcut to the XLA with XLA on the shared drive. If possible you don't want an XLA on a local drive.

If the XLA must be on a local drive - not sure if this would work but an XLS on open event could check an fix any paths and install /install a xla - if it knows where its is. But if you were emailing a XLS over the internet, the on open event of the XLS could check if the XLA is available and put up a message box telling the user what to do - install this xla, which would be a separate attachment. The XLA could clean up any paths as part of its on open event - just some ideas.

another possibility is the XLA on open event can modify the XLSs on open event so that if that XLS is distributed the XLS will be able to check if the XLA is available. Tricky.

回答5:

It's a poor oversight that makes add-ins barely manageable for shared use. Other than this, using .XLAM add-ins is a good way to avoid having to have macro-enabled spreadsheets (the shared spreadsheet can be distributed without macros and the macros can reside in an .XLAM)