В процессе разработки на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда конфигурация обрастает огромным количеством расширений. Если их число исчисляется сотнями (например, более 300), задача поиска конкретного модуля, документа или формы, добавленных сторонними подрядчиками или в рамках разных проектов, превращается в настоящий квест. Стандартные инструменты поиска могут казаться неудобными, если не знать определенных нюансов платформы. В этой статье мы подробно разберем, как эффективно искать изменения в «море» расширений, используя как стандартные, так и продвинутые методы.
Это самый очевидный способ, но у него есть одна важная особенность: платформа ищет только в тех объектах, которые «видны» конфигуратору в данный момент. Разберем по шагам, как правильно настроить глобальный поиск для охвата всех расширений.
Прежде всего, нам необходимо убедиться, что расширения подключены и открыты. Если расширение просто существует в списке, но его дерево метаданных не развернуто, поиск может его проигнорировать. Рассмотрим алгоритм действий:
Ctrl + Shift + F для вызова окна глобального поиска.Проанализируем ситуацию: если документ был именно добавлен в расширении (а не просто заимствован), поиск по имени документа в метаданных быстро выдаст результат. Если же нас интересует изменение в модуле, в строке поиска следует указать уникальную строку кода или имя процедуры.
Если конфигурация является самописной и в ней отсутствует библиотека стандартных подсистем (БСП), мы можем написать простую внешнюю обработку. Это гораздо быстрее, чем перебирать 300 расширений визуально. Программный метод позволяет нам обратиться к коллекции РасширенияКонфигурации и проанализировать состав каждого из них.
Рассмотрим пример кода, который поможет найти, в каком расширении находится документ с определенным именем:
ВыборкаРасширений = РасширенияКонфигурации.Получить();
ИмяИскомогоОбъекта = "ИмяВашегоДокумента";
Для Каждого ТекущееРасширение Из ВыборкаРасширений Цикл
// Проверяем, активно ли расширение и загружено ли оно
МетаданныеРасширения = ТекущееРасширение.ПолучитьМетаданные();
Если МетаданныеРасширения.Документы.Найти(ИмяИскомогоОбъекта) <> Неопределено Тогда
Сообщить("Объект найден в расширении: " + ТекущееРасширение.Имя);
КонецЕсли;
КонецЦикла;
Этот способ хорош тем, что он не требует ручного открытия деревьев метаданных. Мы просто перебираем коллекцию объектов МенеджерРасширенийКонфигурации и используем метод Найти() в соответствующих коллекциях метаданных.
Когда количество расширений зашкаливает, а поиск внутри 1С работает медленно, на помощь приходит консоль дизайнера. Мы можем выгрузить все расширения в текстовые файлы (XML) и воспользоваться мощными инструментами поиска типа Notepad++, VS Code или системной утилитой grep.
Разберем процесс автоматизации выгрузки. Для этого запустим конфигуратор через командную строку с параметром /DumpConfigToFiles. Особенность в том, что нам нужен ключ -AllExtensions, который заставит платформу выгрузить не только основную конфигурацию, но и все подключенные расширения.
Пример команды для запуска:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S"Сервер\База" /N"Админ" /P"Пароль" /DumpConfigToFiles "C:\Distr\AllConfigs" -AllExtensions
После выполнения команды в каталоге C:\Distr\AllConfigs появится множество подпапок, соответствующих каждому расширению. Теперь нам достаточно запустить поиск по файлам в этом каталоге. Ищем файлы с расширением .bsl (модули) или файлы метаданных документов. Этот метод является самым надежным («хардкорным»), так как он позволяет увидеть физическое присутствие кода или объекта в конкретной папке расширения.
Малоизвестный, но эффективный метод — использование стандартных функций платформы в режиме пользователя. В последних версиях платформы 8.3, если у пользователя есть права администратора, можно открыть форму документа и воспользоваться меню «Сервис и настройки» (или кнопка «три точки» в заголовке формы).
Выясним, как это работает:
Важно: если документ добавлен в расширении, платформа подсветит его именно в ветке соответствующего расширения, а не в основной конфигурации. Это самый быстрый способ «точечного» поиска, если вы уже находитесь в интерфейсе программы.
Если ваша задача — понять, какой именно программный код из множества расширений отрабатывает при открытии или записи документа, воспользуемся отладчиком. В условиях, когда расширения могут перекрывать друг друга (используя аннотации &Перед, &После или &Вместо), это единственный способ увидеть реальную последовательность вызовов.
Проанализируем ситуацию с помощью замера производительности:
В итоговой таблице замера мы увидим колонку «Модуль». Путь к модулю в расширении всегда содержит префикс с именем расширения. Сортируя таблицу по времени выполнения или количеству строк, мы легко вычислим все расширения, «приложившие руку» к работе данного документа.
Если документ был добавлен в расширении и это привело к записи данных, информация об этом может отразиться в Журнале регистрации. Платформа фиксирует события метаданных, и в колонке «Метаданные» может отображаться полное имя объекта, включающее имя расширения. Разберем, как это использовать: установим фильтр по искомому объекту и внимательно изучим структуру его полного имени в событиях «Данные.Изменение» или «Данные.Создание».
Работа с 300+ расширениями требует системного подхода. Мы рекомендуем:
Помните, что в иерархии расширений важен их порядок (приоритет). Если одно и то же свойство или модуль изменены в разных расширениях, выполняться они будут согласно их номеру в списке «Расширения конфигурации». Проверка этого порядка часто помогает понять, почему код работает не так, как ожидалось.