The_Prist13-й квартал,

Коллекция CommandBars относится к Application.Да. Есть свойство Get с именем CommandBars имеющее тип CommandBars. (Совпадение имён сбивает с толку, не правда ли?):
The_PristА отношение это прописано в библиотеке "Microsoft Office XX.0 Object Library".Нет. Отношение это прописано в той же библиотеке типов, где описан Application - в library Access. Тип CommandBars описан в library Office, на которую ссылается (импортирует) библиотека Access, чтобы её мог скомпилировать midl:
Но (полная) информация о типах, описанных в импортируемых библиотеках, в компилируемую библиотеку не попадает (иначе творился бы бардак).The_PristЕсли она подключена - то запись CommandBars.Add будет работать и VBA по умолчанию припишет CommandBars к Application, как прописано в типах(как using в C). Но если убрать ссылку на библиотеку "Microsoft Office XX.0 Object Library", то коллекция CommandBars ни к кому не будет отнесена и VBA сочтет её необъявленной процедурой или переменной. И если установлена директива Option Explicit - VBA честно об этом ошибкой и скажет. Если не установлена вышеупомянутая директива - то при попытке создать новую панель получим ошибку отсутствия метода для объекта.Неправильные предпосылки, неправильные выводы. Про то, как свойство get CommandBars попадёт в глобальное пространство имён - см. мой пост выше про appobject. CommandBars.Add вызовется вне зависимости от подключения ссылки на офисную библиотеку в VBA-проекте, вопрос только в связывании - раннем (подключена) или позднем (не подключена).

Павел Жданов,

Если "заработало" без Option Explicit - где-то осталась ошибка.

The_Prist https://msdn.microsoft.com/en-us/library/office/ff821379.aspx И?
Информация по этой ссылке (и дальше) никак не противоречит написанному мной. Это высокоуровневое описание. Я толкую про то, что происходит уровнем ниже.
Или вы воспринимаете слово "once" в фразе Application.CommandBars Property (Access)Once you establish a reference to the CommandBars collection object, you can access all the properties and methods of the object.как признак исключительности - "только так, и никак иначе"?

The_PristМоя ссылка была дана с одной целью: MSDN утверждает, что CommandBars является свойством Application.И IDL-овский текст (приведённый мной) это доказывает. И CallByName (обёртка над IDispatch::Invoke) тоже. MSDN описывает факт. MSDN НЕ говорит о том, что доступ к методам и свойствам дуального (dual) интерфейса возможен исключительно при наличии библиотеки типов (где б тогда были скриптовые языки?).The_PristИ если Application не указывать - будьте добры поставить ссылку, чтобы VBA знал откуда черпать свойство CommandBars(и её методы и свойства) и что в результате выдавать.Третий раз говорю про appobject . Объект Application любого VBA-хоста (купите VBA SDK, и будет у вас свой Notepad с блэкджеком и VBA) имеет этот атрибут, и его методы и свойства попадают в global namespace проекта VBA.The_PristЧтобы у него(VBA) не было двояких толкований и соблазнов(все же офис он такой - может взять не то, что хотим мы, если явно ему не указать).Соблазны-это к живым существам. Пространство для множественного толкования возникает в случае, когда в контексте применения какого-либо символа (имени) таких символов (имён) в текущей области видимости (scope) несколько. Типичная неоднозначность такого рода: Dim rs As Recordset при подключенных библиотеках DAO и ADODB, поскольку тип Recordset есть в обоих. Да, наверное плохо, что нет никакого предупреждения при компиляции. Да, совсем плохо, что анализом исходного кода VBA-проекта невозможно установить приоритет ссылок на библиотеки типов. Вместе с тем, дисциплина разруливания конфликтов имён известна: от inner scope к outer scope для имён, определённых в исходном коде, в порядке подключения (приоритета) библиотек типов для имён из них. Эту дисциплину надо знать и учитывать. Либо же, переходя к рекомендация ставить Application, квалифицировать имена. Рекомендация ставить Application плоха тем, что неполна: если можно "сломать" CommandBars, то можно "сломать" и Application. "Сломать" полную квалификацию (например, Access.Application.CommanBars) уже сложнее, но на форуме периодически попадаются сообщения, в которых люди пытаются это сделать, называя модули теми же именами, что подключенные библиотеки типов.The_PristА в некоторых версиях офиса бывают глюки и похлеще.Глюки бывают везде. На то и глюки (если это глюки, а не by design), чтобы программист не дремал.The_PristИ Microsoft отмалчивается.Заговор, определённо.The_PristЯ пытаюсь описать простыми словами человеку, что если поставить Application, то проблема вероятно исчезнет.Не исчезнет. Другая у него проблема. Он достаточно нормально, на самом деле, описал. Вы же увидели призрак проблемы, с которой вам приходилось сталкиваться, и погнались за ним.The_PristИ никаких лишних .tlb мне не потребовалось таскать с проектом..tlb ему нужна на машине разработчика (с 2010-м), причём, если всё так, как он говорит, от 2007-го, и её не надо таскать на клиентские машины (Reference должен обновиться при переносе на локально зарегистрированную библиотеку типов; впрочем, это лучше проверить). И нужна она ему только (по большому счёту) по причине использования событий классов, в ней описанных.
The_PristВы вот уверены, что для всех версий офиса нигде ничего не заглючивает(особенно в 2007) и все ссылки именно как Вы расписали красиво раскладываются и Application нафиг не нужная приблуда в кодах?Пожалуй, уже ответил выше. Конкретные случаи надо конкретно разбирать, мистические же глюки очень редки, объяснение обычно находится (в рамках описанного).