Справочные библиотеки VBA

Question

Я новичок в VBA и собираю небольшое приложение для макросов для Office. У нас около 80 пользователей с практически идентичными настройками ПК, и к ним могут обращаться все, кроме нескольких пользователей.

Я немного поиграл с автоматизацией доступа к веб-страницам с использованием ссылок на веб-службы, а также загрузил ссылки на среду выполнения сценариев Microsoft в проект. Я попытался запустить его на тестовом ПК, и он пожаловался на отсутствие ссылок.

Я не особенно хочу обходить 80 ПК и загружать ссылки вручную.

Мой вопрос, в основном, заключается в том, как мне управлять распространением этого макро-приложения среди 80 лишних пользователей, чтобы ссылки каждый раз загружались для каждого пользователя.

Спасибо!

Answer 1

Позднее связывание по большей части решит проблемы со ссылками в VBA, если у вас нет необычных ссылок. Большинство проблем вызвано различиями в версиях библиотеки, которые можно преодолеть с помощью позднего связывания. С VBA часто рекомендуется разрабатывать с ранним связыванием, но освобождать с поздним связыванием. Основным недостатком позднего связывания является изменение встроенных констант на значения (скорость больше не является проблемой, которой она раньше была.)

Итак:

Dim fs As Object 'Instead of FileSystemObject '
Dim xl As Object 'Instead of Excel.Application '

Set fs=CreateObject("Scripting.FileSystemObject")
Set xl=CreateObject("Excel.Application")

'Value instead of built-in constant '
ForReading=2
Set f = fs.OpenTextFile("c:\testfile.txt", ForReading)

Answer 2

Если у вас есть ссылки, от которых зависит ваше приложение, и которые, как вы знаете, не будут на целевых ПК, я настоятельно рекомендую вам изучить какую-нибудь технологию установки.

Используя установщик, вы сможете установить свой макрос, а также установить и зарегистрировать все соответствующие ссылки / библиотеки.

Как правило, в Windows есть два варианта: технология Windows Installer и технология Script.

Мы используем InstallShield для всех наших развертываний, хотя есть несколько вариантов использования (есть несколько обсуждений по переполнению стека).

Используя технологию установщика Windows, вы можете создавать установочные файлы MSI, которые затем можно автоматически развертывать с помощью групповой политики.

Answer 3

В дополнение к этому ответу , который является пуленепробиваемым решением для решения такого рода проблем, но который довольно сложен в реализации, вы также можете написать некоторый код, который будет выполняться, когда ваше приложение VBA запускается, проверяя коллекцию 'links' объекта 'application'. Затем вы можете проверить (1), доступны ли запрошенные файлы (dll, ocx, tlb) на компьютере, и (2), если ссылка может быть создана (application.references.addFromFile ...).

Будьте осторожны: объявления объектов, которые могут быть «зависимыми от ссылок», такие как:

Dim cat as ADOX.catalog 

вызовет ошибку компиляции, если ссылка не активна, когда соответствующий модуль «скомпилирован». Затем я советую вам изолировать вашу «процедуру проверки ссылок» в модуле запуска (эквивалентном «autoexec»), который работает только с VBA и базовыми объектами приложения. Проверьте это с помощью файлов справки (пример: в Access по умолчанию ссылки, которые можно использовать без внешних ссылок, это VBA, Access и DAO).

EDIT:

в случае, если внешние ссылки зависят от другого программного пакета и (1) не могут распространяться вместе с файлом MSI или (2) могут иметь несколько версий, я думаю, что «reference.addFromFile» - единственное решение, которое может применяться Пример:

• У вас есть клиент времени выполнения VBA / Access приложение, которое должно ссылаться на Word (файл msword.olb).
• По вопросам лицензирования вы не можете свободно распространять этот файл вместе с пакетом msi
• файл olb может быть либо 'XP-версией, либо более новой *

Наше решение состоит в том, чтобы иметь 2 таблицы в файле клиентского доступа. Один перечисляет все ссылки, которые должны быть проверены или добавлены во время запуска (Word будет одним из них), а другой перечисляет все возможные местоположения файла (в зависимости от того, есть ли у пользователя версия office11 или более новая). один), с отношениями один ко многим между двумя таблицами.

Итак, лучшей стратегией может быть сочетание MSI-пакетов и управления через код:

• msi отлично подходит для распространения независимых DLL или других файлов, которые полностью «встроены» в ваше приложение, таких как элементы управления ActiveX (например, элементы управления сканерами, средства просмотра отчетов или просмотра файлов и т. Д.)
• - лучшее решение, когда вашему приложению придется взаимодействовать с другими приложениями (word, excel, outlook и т. Д.), Которые могут существовать в разных версиях на компьютерах вашего пользователя.

Answer 4

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

Затем просто распространите установочный пакет с надстройкой, которая регистрирует компоненты и регистрирует надстройки в соответствующих приложениях Office.

VB6 может быть хорошей идеей, учитывая его сходство с VBA.