Come arrestare Excel memorizzando il percorso assoluto di un XLA?

Question

Ho un file XLA che deve essere distribuito a un numero di utenti nell'organizzazione come componente aggiuntivo di Excel. La mia intenzione è di distribuirla in una directory nella cartella "documenti e impostazioni" dell'utente in "Dati applicazione \ MyCompany". (In effetti, tutto questo funziona attraverso un wrapper che copia localmente la versione più recente di XLA e lo installa come componente aggiuntivo di Excel).

Tuttavia, se un utente crea un foglio che fa riferimento a una funzione definita in questo XLA, Excel sembra memorizzare il percorso assoluto di XLA nella chiamata di funzione. Pertanto, se l'utente invia il foglio a un collega, Excel non riesce a risolvere la funzione poiché la sua copia di XLA risiede in un percorso assoluto diverso (poiché il loro nome utente fa parte del percorso assoluto).

La mia convinzione fino ad ora era che l'Excel "si adattava" con questo purché XLA fosse installato come componente aggiuntivo ma questo non sembra essere il caso.

È davvero il caso che sia necessario applicare un percorso assoluto identico per il mio componente aggiuntivo per tutti gli utenti? Questo è possibile all'interno di una singola organizzazione, ma onestamente non posso credere che questo sia vero in quanto ostacola seriamente la condivisione di file XLS.

Grazie.

Answer 1

Non c'è un buon modo per farlo. Metto i miei file xla su una condivisione di rete piuttosto che localmente e li installo tramite il percorso UNC. Questo funziona solo per me perché tutti hanno accesso alla condivisione, il che potrebbe non essere il tuo caso. Ecco alcune altre alternative

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

Answer 2

È possibile specificare un percorso basato su variabile di ambiente? Per esempio. %APPDATA%\MyCompany

Answer 3

ho semplicemente rimuovere il percorso con un sub come questo:

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

Quello che ho fatto è che se io do un utente un XLS, ha nella sua sulla evento aperto codice che - installa il XLA come parte del suo evento aperto. Disinstalla anche la versione precedente se presente (cancella e barre dei comandi). Questo auto distribuisce. In teoria potrebbe ripulire qualsiasi percorso. Ciò presuppone che ci sia un'unità condivisa accessibile a tutti, in questo modo non si riesce a copiare l'unità XLA sul disco locale. In alternativa, invia loro un collegamento a XLA con XLA sull'unità condivisa. Se possibile, non si desidera un XLA su un'unità locale.

Se l'XLA deve trovarsi su un'unità locale, non è sicuro se ciò funzionerebbe, ma un evento XLS su evento aperto potrebbe controllare una correzione dei percorsi e installare/installare un xla - se sa dove si trova. Ma se si inviava via e-mail un XLS su Internet, l'evento open di XLS poteva verificare se XLA è disponibile e mettere una finestra di messaggio che diceva all'utente cosa fare - installare questo xla, che sarebbe un allegato separato. La XLA può ripulire qualsiasi percorso come parte del suo evento aperto - solo alcune idee.

un'altra possibilità è che l'evento XLA su evento aperto possa modificare gli XLS sull'evento aperto in modo che, se viene distribuito questo XLS, l'XLS sarà in grado di verificare se XLA è disponibile. Difficile.

Answer 5

È una cattiva supervisione che rende i componenti aggiuntivi difficilmente gestibili per l'uso condiviso. Oltre a questo, usare i componenti aggiuntivi .XLAM è un buon modo per evitare di avere fogli di calcolo abilitati per le macro (il foglio di calcolo condiviso può essere distribuito senza macro e le macro possono risiedere in un .XLAM)