Comment arrêter Excel stocker le chemin absolu à un XLA?

Question

J'ai un fichier XLA à déployer pour un certain nombre d'utilisateurs dans l'organisation en tant que complément Excel. Mon intention est de le déployer dans un répertoire du dossier "documents and settings" de l'utilisateur dans "Application Data \ MyCompany". (En fait, tout cela fonctionne à travers un wrapper qui copie localement la dernière version de l'XLA et l'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 fichier XLA, Excel apparaît pour stocker le chemin absolu du fichier XLA dans l'appel de fonction. Ainsi, si l'utilisateur envoie la feuille à un collègue, Excel ne parvient pas à résoudre la fonction car leur copie du fichier XLA réside dans un chemin absolu différent (car leur nom d'utilisateur fait partie du chemin absolu). Jusqu'à présent, je croyais que l'Excel «s'en accommodait» tant que le XLA était installé en tant que complément, mais cela ne semble pas être le cas.

Est-ce vraiment le cas que j'ai besoin d'appliquer un chemin absolu identique pour mon add-in pour tous les utilisateurs? C'est possible au sein d'une seule organisation mais honnêtement, je ne peux pas croire que cela soit vrai car cela entrave sérieusement le partage de fichiers XLS.

Merci.

Answer 1

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

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

Answer 2

Pouvez-vous spécifier un chemin d'accès basé sur une variable d'environnement? Par exemple. %APPDATA%\MyCompany

Answer 3

je supprimer simplement le chemin avec un sous 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 4

Ce que je l'ai fait est que si je donne un utilisateur un XLS, il a sur sa open event du code qui - installe le XLA dans le cadre de son événement on open. Il désinstalle également l'ancienne version le cas échéant (barre de suppression et de commande). Ce moi-même distribue. En théorie, il pourrait nettoyer tous les chemins. Cela suppose qu'il existe un lecteur partagé auquel tout le monde peut accéder, ce qui les empêche de copier le fichier XLA sur le lecteur local. Vous pouvez également leur envoyer un raccourci vers le XLA avec XLA sur le lecteur partagé. Si possible, vous ne voulez pas un XLA sur un disque local. Si le XLA doit être sur un lecteur local - pas sûr si cela fonctionnerait mais un événement XLS sur open pourrait vérifier un réparer tous les chemins et installer/installer un xla - si elle sait où c'est. Mais si vous envoyiez un XLS par Internet, l'événement on open du XLS pourrait vérifier si la XLA est disponible et afficher une boîte de message indiquant à l'utilisateur ce qu'il doit faire - installez ce xla, qui serait une pièce jointe séparée. Le XLA pourrait nettoyer tous les chemins dans le cadre de son événement ouvert - juste quelques idées.

Une autre possibilité est que l'événement XLA sur open puisse modifier les XLS sur un événement ouvert de sorte que si XLS est distribué, le XLS pourra vérifier si le XLA est disponible. Rusé.

Answer 5

Il s'agit d'une mauvaise surveillance qui rend les compléments à peine gérables pour une utilisation partagée. Autre que cela, l'utilisation de compléments .XLAM est un bon moyen d'éviter d'avoir des feuilles de calcul à extension macro (la feuille de calcul partagée peut être distribuée sans macros et les macros peuvent résider dans un fichier .XLAM)