Какова область применения надстроек Excel и ссылок на VBA?

Когда я устанавливаю надстройку (с помощью флажка), какие правила/механизмы определяют, как долго эта надстройка остается установленной? Кажется, что он установлен на уровне приложения, а это означает, что он применяется к любой книге в приложении Excel, пока вы сами не снимите флажок. Если это верно, это означает, что пока пользователь устанавливает надстройку самостоятельно, с ним все должно быть в порядке; но им придется установить его в первый раз (что можно сделать программно).

Что касается ссылок VBA, я полагаю, что их не нужно «проверять» каждый раз, то есть это входит в объем документа. Но если это так, то почему люди рекомендуют использовать методы позднего связывания, когда программное обеспечение готово к распространению? Является ли позднее связывание только для того, чтобы сделать его совместимым с разными версиями, но не обязательно для того, чтобы DLL «проверялась» как ссылка? Исходя из этого предположения, если все используют ту же версию Excel, что и я, будет ли безопасно отказаться от позднего связывания всех вместе и просто добавить ссылки вручную?


excel vba add-in
person iliketocode    schedule 10.10.2014    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Надстройки устанавливаются на уровне приложений. Вы можете точно настроить, как надстройка может быть представлена ​​(или нет) для различных книг с помощью Ribbon XML, если это необходимо.

пока пользователь устанавливает надстройку у себя, все должно быть в порядке; но они должны будут установить его в первый раз

Да, придется установить.

Что касается ссылок VBA, я полагаю, что их не нужно «проверять» каждый раз, то есть это входит в объем документа.

Да, контроль версий. Это также избавляет вас от необходимости программно добавлять ссылки. Это можно сделать по пути (что требует знания ОС, версии и т. д.) или GUID (на самом деле мне никогда не удавалось это сделать успешно). Оба они затем потребуют отлова ошибок (что, если путь не существует или недоступен по иным причинам? и т. д.). Так что просто используйте позднее связывание.

Хотя разработка с использованием раннего связывания полезна из-за интеллектуального смысла, с точки зрения пользователя, как правило, нет заметной разницы в том, как они могут работать, хотя EB, возможно, быстрее, разница обычно незначительна для большинства приложений. В связи с этим, если при использовании EB вы полагаетесь на ключевое слово New для создания экземпляров объектов, я считаю, что функция CreateObject, которую вы использовали бы с LB, на самом деле быстрее. Хотя, наверное, это не заметно.

могу ли я полностью отказаться от позднего связывания и быть в безопасности, просто добавив ссылки вручную?

Я бы просто выполнял разработку с помощью EB, а затем модифицировал код для объектов с поздней привязкой перед компиляцией надстройки.

person David Zemens    schedule 10.10.2014
comment
Это звучит как план. Я действительно слышал, что LB медленнее, чем EB. Вот веб-сайт support.microsoft.com/kb/245115. Раннее связывание является предпочтительным методом. Это лучший вариант, потому что ваше приложение привязывается непосредственно к адресу вызываемой функции, и при выполнении поиска во время выполнения не возникает дополнительных накладных расходов. С точки зрения общей скорости выполнения, она как минимум в два раза быстрее позднего связывания. Итак, если бы у меня была функция, возвращающая набор записей ADODB.recordset, я бы просто изменил тип возвращаемого значения на «объект»? ? - person iliketocode; 10.10.2014
comment
Да, вы бы сделали как Dim ado as Object 'ADODB.Recordset, но это было бы сложнее, вам также нужно будет конкретно перечислить любые константы, используемые в этой ссылке на библиотеку, например, вам нужно будет Const adLockReadOnly as Long = 1 и т. д. для любых констант, которые используют ваши функции . - person David Zemens; 10.10.2014

arrow_upward
3
arrow_downward

Использование позднего связывания лучше, потому что вы не можете гарантировать, что в каждой системе будут доступны одни и те же ссылки. Таким образом, вы должны выбирать только ссылки, которые, как вы можете гарантировать, будут на каждой машине, и распространять файлы DLL для остальных.

Что касается объема, общедоступные подпрограммы/функции/переменные в вашей надстройке будут доступны для всего в приложении, пока оно установлено и активно. Ссылки в надстройке будут доступны только для подпрограмм в надстройке.

person Mr. Mascaro    schedule 10.10.2014
comment
Ну, если предположить, что все, кому я даю программу, будут работать с одной и той же версией Excel, значит ли это, что я могу просто выполнить раннее связывание для всего? И если я правильно понимаю, используя позднее связывание, он просто делает что-то вроде поиска объекта с именем ADODB.connection среди списка доступных ссылок? Так что это не должно быть конкретной версии? - person iliketocode; 10.10.2014
comment
Нет. Это зависит от многих других факторов. Например, в нашей организации только 10 % пользователей имеют ссылки на выполнение регулярных выражений в VBA, и все они имеют одну и ту же версию всего. - person Mr. Mascaro; 10.10.2014
comment
Как насчет добавления ссылок на саму надстройку? Примечательно, потому что, чтобы иметь возможность программно использовать функциональные возможности надстройки, вы должны добавить ее в качестве ссылки. Будет ли это проблемой? Я бы предположил, что нет, потому что надстройка всегда должна отображаться, если она установлена ​​​​и открыта. - person iliketocode; 10.10.2014
comment
Добавление ссылки не помещает DLL (или OCX и т. д.) в надстройку. Эта ссылка все еще должна быть установлена ​​на целевой машине. - person Mr. Mascaro; 10.10.2014

arrow_upward
-1
arrow_downward

Мне было очень трудно внедрить надстройку в Excel.
У меня есть кнопки на листе, которые ссылаются на код в надстройке, и у меня также есть код на листе, который ссылается на функции в Надстройка. Что меня действительно сбивало с толку, так это то, что я мог деактивировать надстройку (параметры, надстройки, управление, снять отметку), а код продолжал получать доступ к надстройке. Это было особенно неприятно во время разработки и отладки надстройки, потому что я хотел деактивировать надстройку (во время разработки) и сделать так, чтобы мой рабочий лист приложения ссылался на открытый файл разработки надстройки .xlsm. Мне потребовалось некоторое время, чтобы понять, что из-за кода «Ссылки» на листе приложения он все еще вызывает код в файле .xlam, а не в .xlsm.

Как только я понял это, все стало более гладко, но теперь, каждый раз, когда я вношу изменения и хочу протестировать, мне нужно закрыть приложение, деактивировать надстройку, закрыть Excel, сохранить мой .xlsm как .xlam по умолчанию Каталог надстроек Excel (для которого, кстати, требуются права администратора), откройте Excel, активируйте надстройку. [Закрыть Excel], Откройте приложение моей рабочей книги. Весьма утомительный процесс. Возможно, я мог бы пропустить последний шаг [Закрыть Excel], если надстройка становится активной сразу после проверки.

И тогда работа с пользователями на Win10 и Win7 действительно усложняет ситуацию. Другой путь к папке надстроек по умолчанию. Пользователям приходится менять путь к ссылкам и т. д. Очень некрасиво. Очень Майкрософт.

person Randy Sonnicksen    schedule 10.03.2019