Как остановить Excel, хранящий абсолютный путь к XLA? - PullRequest
Новая
       46

Как остановить Excel, хранящий абсолютный путь к XLA?

6 голосов
/ 22 июля 2010

У меня есть файл XLA, который должен быть развернут на нескольких пользователях в организации в виде надстройки Excel.Мое намерение состоит в том, чтобы развернуть его в каталог в папке «документы и настройки» пользователя в «Application Data \ MyCompany».(На самом деле все это работает через оболочку, которая локально копирует последнюю версию XLA и устанавливает ее как надстройку Excel).

Однако, если пользователь создает лист, который ссылается на функцию, определенную вэтот XLA, а затем Excel, чтобы сохранить абсолютный путь XLA в вызове функции.Таким образом, если пользователь отправляет лист коллеге, Excel не удается разрешить функцию, поскольку его копия XLA находится по другому абсолютному пути (поскольку его имя пользователя является частью абсолютного пути).

Мое убеждениедо сих пор Excel просто «справлялся» с этим, пока XLA был установлен как надстройка, но это, похоже, не так.

Действительно ли это тот случай, когда мне нужно применятьидентичный абсолютный путь для моей надстройки для всех пользователей?Это возможно в рамках одной организации, но я, честно говоря, не могу поверить, что это правда, поскольку это серьезно затрудняет обмен файлами XLS.

Спасибо.

Ответы [ 5 ]

5 голосов
/ 22 июля 2010

Нет хорошего способа сделать это.Я помещаю свои файлы xla в общий сетевой ресурс, а не локально, и устанавливаю их по пути UNC.Это работает только для меня, потому что каждый имеет доступ к общему ресурсу, что может быть не так.Вот некоторые другие альтернативы

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

2 голосов
/ 02 июля 2013

Я просто удаляю путь с подпрограммой, подобной этой: 

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
0 голосов
/ 28 июля 2017

Это плохой контроль, который делает надстройки практически неуправляемыми для совместного использования. Помимо этого, использование надстроек .XLAM - это хороший способ избежать необходимости иметь таблицы с поддержкой макросов (общая таблица может распространяться без макросов, а макросы могут находиться в .XLAM)

0 голосов
/ 29 ноября 2013

То, что я сделал, если я дам пользователю XLS, он имеет в своем событии открытия некоторый код, который устанавливает XLA как часть его в событии открытия. Он также удаляет старую версию, если таковая имеется (удаление и панели команд). Это сам распределяет. Теоретически это может очистить любые пути. Это предполагает наличие некоторого общего диска, к которому все могут получить доступ, что предотвращает копирование XLA на локальный диск. Или отправьте им по электронной почте ярлык на XLA с XLA на общем диске. Если возможно, вам не нужен XLA на локальном диске.

Если XLA должен быть на локальном диске - не уверен, что это будет работать, но событие XLS при открытии может проверить исправление любых путей и установить / установить xla - если он знает, где находится. Но если вы отправляете XLS по электронной почте через Интернет, событие открытия XLS может проверить, доступен ли XLA, и вывести сообщение, сообщающее пользователю, что делать - установите этот xla, который будет отдельным вложением. XLA может очистить любые пути как часть своего открытого события - только некоторые идеи.

другая возможность - событие XLA при открытии может изменить XLS при событии открытия, так что если этот XLS распределен, XLS сможет проверить, доступен ли XLA. Tricky.

0 голосов
/ 22 июля 2010

Можете ли вы указать путь на основе переменных среды? Например. %APPDATA%\MyCompany

...