При работе с платформой 1С:Предприятие 8.3 разработчики часто сталкиваются с ситуацией, когда привычные механизмы расширений, идеально работающие в управляемом приложении, ведут себя непредсказуемо или вовсе не функционируют в режиме обычного приложения (толстого клиента). Одной из таких проблем является попытка модификации стандартного интерфейса. В данной статье мы детально разберем, почему добавление пунктов в ветку Интерфейсы внутри расширения не дает результата, и рассмотрим эффективные обходные пути.
Рассмотрим стандартную ситуацию: у нас есть конфигурация на обычных формах (например, УПП 1.3 или старая редакция КА). Мы создаем расширение, заимствуем в него объект из ветки Общие -> Интерфейсы (например, Интерфейс_общий), добавляем туда новое меню или пункты, привязываем к ним команды запуска новых отчетов, созданных в этом же расширении. Казалось бы, все сделано верно: роли настроены, права даны, расширение активно. Однако при запуске программы в режиме обычного приложения мы не видим никаких изменений.
Причина кроется в архитектуре платформы. Механизм расширений изначально проектировался для управляемого интерфейса. В управляемом приложении командный интерфейс (панель разделов, навигация) строится динамически путем слияния данных основной конфигурации и всех подключенных расширений. В обычном же приложении дерево главного меню строится статически при запуске системы на основе метаданных объекта Интерфейс исключительно из основной конфигурации.
Проанализируем ключевые моменты этого ограничения:
КомандныйИнтерфейс — это гибкий объект, обычный интерфейс не поддерживает механизм "слияния" (merge) при применении расширения.Поскольку мы не можем изменить главное меню, наиболее логичным и стабильным решением будет добавление кнопок или ссылок для вызова ваших новых объектов непосредственно на существующие формы (например, на форму списка справочника или в "Рабочий стол").
Разберем этот процесс по шагам:
1. В расширении заимствуем ту форму, на которую хотим добавить кнопку. Например, ФормаСписка справочника Контрагенты.
2. Добавляем новую команду формы или просто кнопку в командную панель.
3. В обработчике нажатия кнопки пишем код вызова нашего отчета или обработки, которые находятся в расширении.
Проанализируем пример кода для вызова отчета из расширения в обычной форме:
Процедура ДействиеДобавленнойКнопки(Кнопка)
// Получаем отчет из расширения
ИмяОтчета = "МойНовыйОтчетИзРасширения";
ОтчетОбъект = Отчеты[ИмяОтчета].Создать();
// Если отчет на обычных формах
Форма = ОтчетОбъект.ПолучитьФорму();
Форма.Открыть();
КонецПроцедуры
Этот метод работает безотказно, так как расширение форм (добавление новых реквизитов и элементов управления) полностью поддерживается платформой даже в обычном приложении.
Для опытных разработчиков существует возможность программно манипулировать интерфейсом. Хотя мы не можем изменить структуру интерфейса в метаданных расширения, мы можем попробовать внедрить код в модуль приложения или в обработчики главной формы (если используется концепция "Рабочего стола").
Выясним, как это реализовать. Нам необходимо перехватить процедуру ПриНачалеРаботыСистемы или ПередОткрытием главной формы. Однако стоит учитывать, что в обычном приложении доступ к главному меню из встроенного языка крайне ограничен. В ряде случаев разработчики используют COM-объекты для манипуляции окном 1С, но это решение считается "костыльным" и не рекомендуется для стабильных систем.
Если в вашем обычном приложении разрешено использование управляемых форм (как указано в условиях вопроса), мы можем пойти другим путем. Рассмотрим использование командного интерфейса подсистем.
1. В расширении создадим новую Подсистему.
2. Включим в эту подсистему наш новый отчет.
3. Установим свойство подсистемы Включать в командный интерфейс.
4. В настройках пользователя или через "Настройку панели разделов" (если она доступна в вашем гибридном режиме) можно вывести эту подсистему.
Важное примечание: Этот пункт меню появится не в старом дереве Интерфейсы, а в панели разделов управляемого интерфейса, если она отображается в вашем клиенте.
Если ваша конфигурация содержит БСП (Библиотека стандартных подсистем), это самый правильный архитектурный путь. Вместо того чтобы пытаться "пропихнуть" отчет в жесткое меню через расширение, воспользуйтесь штатным механизмом регистрации внешних обработок.
Разберем преимущества этого метода:
Подводя итог, проанализируем ситуацию еще раз: если вы работаете в Толстом клиенте (Обычное приложение), забудьте про модификацию ветки Интерфейсы в расширениях. Платформа визуально позволяет это делать, но фактически игнорирует эти данные при выполнении.
Рекомендованный алгоритм действий:
Таким образом, понимание границ возможностей расширений в обычном приложении экономит время разработчика и позволяет находить более надежные способы доставки функционала конечным пользователям.