Разработчики, активно занимающиеся отладкой в среде 1С:Предприятие, регулярно сталкиваются с раздражающей технической особенностью конфигуратора — так называемым «эффектом дёрганых окон». Стоит только включить автоматическое подключение к фоновым заданиям, как при попытке пошагового выполнения кода конфигуратор начинает лавинообразно открывать вкладки стандартных общих модулей, модуля сеанса и системных процедур. Вместо того чтобы сосредоточиться на логике своего алгоритма, программист вынужден тратить время на закрытие десятков ненужных окон.
В этой статье мы подробно разберем природу этого поведения среды разработки, выясним причины его возникновения и рассмотрим эффективные практические способы решения проблемы, которые позволят вам отлаживать код комфортно и без хаоса в конфигураторе.
Прежде чем перейти к методам устранения проблемы, проанализируем ситуацию с технической точки зрения. Клиент-серверная архитектура платформы 1С:Предприятие по своей сути многопоточна. Когда в конфигураторе включена опция автоматического перехвата (меню «Отладка» — «Подключение» — «Автоматическое подключение» — флажок «Фоновые задания»), отладчик начинает регистрировать и подключать абсолютно все процессы, запускаемые на сервере под вашей учетной записью.
Современные типовые конфигурации (особенно построенные на базе Библиотеки стандартных подсистем — БСП) в фоновом режиме выполняют колоссальное количество служебных задач: расчеты итогов, обновление полнотекстового поиска, синхронизацию данных, рассылку уведомлений и получение почты. Как только стартует очередное служебное фоновое задание:
МодульСеанса (в частности, обработчик УстановкаПараметровСеанса).Поскольку отладчик привязан ко всем фоновым процессам, он добросовестно переходит к исполнению этих инициализирующих процедур. Для отображения текущей строки исполнения конфигуратор вынужден открывать файлы соответствующих модулей. Даже если вы не нажимали кнопку «Шагнуть внутрь» (F11) и надеялись просто дождаться следующей точки останова (F5) в своем модуле, среда разработки все равно покажет вам весь процесс создания новых сеансов изнутри.
Рассмотрим четыре надежных способа справиться с этой проблемой.
Если ваша конфигурация разработана с использованием Библиотеки стандартных подсистем (а это практически все современные конфигурации: БП, ERP, КА, УТ, ЗУП), разработчики БСП уже предусмотрели штатный механизм обхода фоновых заданий. Мы можем заставить систему выполнять фоновые алгоритмы синхронно в рамках нашего текущего клиентского сеанса.
Разберем этот процесс по шагам:
РежимОтладки (без кавычек). Если там уже есть другие параметры, укажите их через пробел.Как это работает под капотом? Функции общего модуля БСП ДлительныеОперации (например, функция ЗапуститьВыполнениеВФоне) при старте анализируют параметры запуска сеанса. Если система обнаруживает строковый параметр РежимОтладки, выполнение кода не передается фоновому заданию на сервере. Вместо этого алгоритм запускается непосредственно в вашем клиентском потоке. Для платформы это выглядит как обычный синхронный вызов. Отладчику больше не нужно подключаться к сторонним сеансам, и лавина окон прекращает открываться.
Вы также можете управлять этим поведением непосредственно из кода, принудительно отключая фоновое выполнение при создании структуры параметров:
ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияВФоне(УникальныйИдентификатор);
ПараметрыВыполнения.ЗапуститьВФоне = Ложь;
Результат = ДлительныеОперации.ЗапуститьВыполнениеВФоне(ИмяПроцедуры, ПараметрыПроцедуры, ПараметрыВыполнения);
Бывают ситуации, когда вам критически важно отладить код именно в контексте реального фонового задания (например, для проверки корректности работы с временным хранилищем или проверки прав доступа под системным пользователем). В этом случае использовать параметр РежимОтладки нельзя, но можно применить хитрость с ручным управлением сеансами отладки.
Рассмотрим этот алгоритм:
Если на сервере параллельно работает множество пользователей и под ними постоянно запускаются фоновые процессы, ваш отладчик может перехватывать чужие сеансы. Чтобы этого избежать, настройте условную фильтрацию точек останова.
Посмотрим, как ограничить прерывание выполнения конкретными условиями:
Пример условия по имени пользователя:
ИмяПользователя() = "Администратор"
Пример условия по конкретному значению параметра сеанса:
ПараметрыСеанса.ТекущийПользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ", Новый УникальныйИдентификатор("ваш-guid-здесь"))
При таком подходе отладчик будет игнорировать инициализацию фоновых процессов других пользователей, не будет открывать лишние окна модулей сеанса и остановится только тогда, когда условие вернет значение Истина.
Довольно популярный среди опытных разработчиков метод — это изоляция сложной бизнес-логики от фонового механизма на этапе написания кода. Если алгоритм не завязан жестко на асинхронный контекст, его гораздо проще спроектировать и отладить во внешней обработке.
Проанализируем этот подход подробнее:
Важное примечание: Если вы отлаживаете механизмы БСП (например, печатные формы или обработки заполнения объектов), внешнюю обработку необходимо предварительно зарегистрировать в справочнике ДополнительныеОтчетыИОбработки. Попытка запустить внешнюю обработку напрямую через «Файл» — «Открыть» в контексте вызова функций БСП может привести к ошибкам прав доступа или неверному определению безопасного режима работы на сервере.
Мы подробно разобрали причины некорректного поведения окон при отладке и изучили четыре практических метода борьбы с «эффектом дёрганых окон». Для большинства повседневных задач разработки в конфигурациях на базе БСП самым быстрым и эффективным решением является использование параметра запуска РежимОтладки, который полностью нейтрализует фоновое выполнение на время разработки. В случаях, когда фоновый режим принципиально важен, используйте комбинацию временного отключения автоподключения и условных точек останова.