Comment arrêter Excel stocker le chemin d'accès absolu à un XLA?

Question

J'ai un fichier XLA, qui est à être déployé sur un nombre d'utilisateurs dans l'organisation comme un complément Excel.Mon intention est de le déployer sur un répertoire de l'utilisateur dans le dossier "documents and settings" dans le dossier "Application Data\MyCompany".(En fait, c'est tout de travail par le biais d'un wrapper qui copie la dernière version de l'XLA localement et installe comme un complément Excel).

Toutefois, si un utilisateur crée une feuille qui fait référence à une fonction définie dans ce XLA Excel s'affiche pour stocker le chemin d'accès absolu du XLA dans l'appel de fonction.Ainsi, si l'utilisateur envoie la feuille à un collègue Excel ne parvient pas à régler la fonction de copie de l'XLA réside dans un autre chemin d'accès absolu (comme leur nom d'utilisateur est une partie du chemin d'accès absolu).

Ma conviction jusqu'à maintenant le Excel "juste fait face" avec ce, aussi longtemps que le XLA a été installé comme un complément, mais cela ne semble pas être le cas.

Est-ce vraiment le cas que j'ai besoin de mettre en place un identique chemin absolu pour mon complément pour tous les utilisateurs?C'est possible au sein d'une seule organisation, mais honnêtement, je ne peux pas croire que c'est vrai que c'gravement nuit à l'échange de fichiers XLS.

Merci.

Answer 1

Il n'y a pas de bon moyen de le faire.Je pose mes fichiers XLA sur un partage réseau plutôt que localement et installez-les via le chemin UNC.Cela ne fonctionne que pour moi parce que tout le monde a accès à la part, ce qui pourrait ne pas être le cas pour vous.Voici quelques autres alternatives

http:// www.DailyDoseOfexcel.com / Archives / 2008/06/02 / Fixation-Links-to-UDFS-in-Addins /

Answer 2

Je retirais simplement le chemin avec un sous-ci comme celui-ci:

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

Answer 3

Pouvez-vous spécifier une variable d'environnement à base de chemin?E. g. %APPDATA%\MyCompany

Answer 4

Ce que j'ai fait est si je donne à un utilisateur un XLS, il a dans son événement ouvert certains code qui - installe le XLA dans le cadre de son événement ouvert. Il désinstalle également la version ancienne si vous utilisez des barres (Supprimer et commander). Ce auto distribue. En théorie, cela pourrait nettoyer tous les chemins. Cela suppose qu'il existe un lecteur partagé que tout le monde peut accéder, cela les empêche de copier le XLA à la conduite locale. Alternativement, envoyez-leur un raccourci vers le XLA avec XLA sur le lecteur partagé. Si possible, vous ne voulez pas de XLA sur un lecteur local.

Si le XLA doit être sur un lecteur local - je ne sais pas si cela fonctionnerait, mais un événement XLS sur Open pourrait vérifier un correctif des chemins et installer / installer un XLA - si elle sait où elle est. Mais si vous envoyiez un courriel sur Internet sur Internet, l'événement ON OUVERT des XLS pourrait vérifier si le XLA est disponible et mettre en place une boîte de message indiquant à l'utilisateur quoi faire - installer ce XLA, ce qui serait une pièce jointe distincte. Le XLA pourrait nettoyer tous les chemins dans le cadre de son événement ouvert - juste quelques idées.

Une autre possibilité est que la XLA sur Open Event peut modifier les XLSS lors de l'événement ouvert de sorte que si ce XLS soit distribué, les XLS pourront vérifier si le XLA est disponible. Délicat.

Answer 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)