Cómo detener Excel almacenando la ruta absoluta a un XLA?

Question

Tengo un archivo XLA que se implementará en varios usuarios de la organización como un complemento de Excel. Mi intención es implementarlo en un directorio en la carpeta "documentos y configuraciones" del usuario en "Datos de la aplicación \ Mi Empresa". (De hecho, todo esto funciona a través de un contenedor que copia localmente la última versión del XLA y lo instala como un complemento de Excel).

Sin embargo, si un usuario crea una hoja que hace referencia a una función definida en este XLA, Excel parece almacenar la ruta absoluta de XLA en la llamada a la función. Por lo tanto, si el usuario envía la hoja a un colega, Excel no puede resolver la función, ya que su copia del XLA reside en una ruta absoluta diferente (ya que su nombre de usuario es parte de la ruta absoluta).

Mi creencia hasta ahora era que el Excel "acaba de hacer frente" a esto, siempre y cuando el XLA se instaló como un complemento, pero este no parece ser el caso.

¿Es realmente el caso que necesito imponer una ruta de acceso absoluta idéntica para mi complemento para todos los usuarios? Esto es posible dentro de una sola organización, pero honestamente no puedo creer que esto sea cierto, ya que impide el uso compartido de archivos XLS.

Gracias.

Answer 1

No hay una buena manera de hacerlo. Puse mis archivos xla en una red compartida en lugar de localmente e los instalé a través de la ruta UNC. Eso solo funciona para mí porque todos tienen acceso a la acción, lo que puede no ser el caso para ti. Aquí hay algunas otras alternativas

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

Answer 2

¿Se puede especificar una ruta basada en variables de entorno? P.ej. %APPDATA%\MyCompany

Answer 3

simplemente me eliminar la ruta con un sub como éste:

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

Lo que he hecho es si doy un usuario de un XLS, que tiene en sus actuales evento abierto código que instala el XLA como parte de su evento abierto. También desinstala la versión anterior si la hay (barras de eliminación y comando). Este auto distribuye. En teoría, podría limpiar cualquier camino. Esto supone que hay alguna unidad compartida a la que todos pueden acceder, esto les impide copiar el XLA a la unidad local. Alternativamente, envíeles un atajo por correo electrónico al XLA con XLA en la unidad compartida. Si es posible, no desea un XLA en un disco local.

Si el XLA debe estar en una unidad local, no estoy seguro de si esto funcionaría, pero un XLS en evento abierto podría verificar una solución de rutas e instalar/instalar una xla, si sabe dónde está. Pero si estaba enviando un XLS a través de Internet, el evento abierto del XLS podría verificar si el XLA está disponible y colocar un cuadro de mensaje que le diga qué hacer: instalar este xla, que sería un archivo adjunto por separado. El XLA podría limpiar cualquier camino como parte de su evento abierto, solo algunas ideas.

Otra posibilidad es que el evento abierto XLA pueda modificar los XLS en un evento abierto, de modo que si ese XLS se distribuye, el XLS podrá verificar si el XLA está disponible. Difícil.

Answer 5

Es un error de supervisión que hace que los complementos apenas sean manejables para uso compartido. Aparte de esto, el uso de complementos .XLAM es una buena manera de evitar tener que tener hojas de cálculo habilitadas para macros (la hoja de cálculo compartida puede distribuirse sin macros y las macros pueden residir en un .XLAM)