Как определить контекст выполнения в отладчике 1С и почему отличается поведение под разными RDP-пользователями

← На главную

В процессе разработки и отладки конфигураций на платформе 1С:Предприятие 8.3 (особенно на управляемых формах, таких как 1С:Бухгалтерия 3.0) разработчики часто сталкиваются со странным поведением отладчика в файловом режиме. Типичный сценарий: один и тот же код в модуле набора записей регистра или модуле объекта под одним пользователем RDP успешно отлаживается и заходит внутрь инструкций препроцессора, а под другим пользователем RDP — просто проскакивает мимо этих блоков.

В этой статье мы подробно разберем, почему возникает такая разница в поведении среды выполнения, как устроена работа препроцессора в файловом варианте базы данных и какие существуют гарантированные способы определить текущий контекст выполнения прямо во время сеанса отладки.

Почему поведение отладки различается под разными пользователями RDP?

Многие ошибочно полагают, что в файловой базе данных «1С:Предприятия» на управляемых формах все процессы всегда выполняются в одном и том же контексте. Однако это не так. Разница в поведении отладчика у различных пользователей в терминальной сессии (RDP) обусловлена двумя ключевыми техническими факторами.

1. Различные настройки запуска клиентского приложения (файл ibases.v8i)

У каждого пользователя операционной системы Windows формируется свой собственный профиль, где хранятся индивидуальные настройки списка баз. Этот файл расположен по пути: %APPDATA%\1C\1CEstart\ibases.v8i. В данном файле для каждой информационной базы прописаны параметры запуска:

Один пользователь RDP запускает базу в режиме Тонкого клиента (в настройках запуска указано DefaultApp=1CV8C или выбран режим «Выбирать автоматически», который по умолчанию стартует тонкий клиент).
У другого пользователя RDP в настройках этой же информационной базы может быть принудительно установлен режим запуска Толстый клиент (управляемое приложение) (параметр DefaultApp=1CV8).

При запуске в режиме толстого клиента управляемого приложения препроцессор платформы ведет себя иначе, чем в тонком клиенте. В толстом клиенте код клиента и эмулируемый код сервера выполняются в рамках одного и того же физического процесса на локальном компьютере, что напрямую влияет на компиляцию блоков #Если Сервер.

2. Настройки подключения предметов отладки и права брандмауэра

В файловом режиме при работе через Тонкий клиент платформа имитирует клиент-серверное взаимодействие. Для этого запускается отдельный поток — так называемый локальный файловый сервер. В результате в системе регистрируются два независимых предмета отладки: клиентское приложение (Тонкий клиент) и серверный контекст (Файловый сервер).

Если у одного из пользователей RDP в конфигураторе не настроено автоматическое подключение серверных сеансов, отладчик будет игнорировать серверный код:

Откроем меню Отладка -> Настройка отладки...
Проверим наличие флага «Автоматически подключать -> Серверные процедуры и функции». Если этот флаг снят, отладчик Тонкого клиента никогда не остановится на точках останова внутри блоков #Если Сервер.
Также на уровне сессии конкретного RDP-пользователя сетевые порты отладки (по умолчанию из диапазона 1560–1591) могут блокироваться локальным брандмауэром Windows, из-за чего подключение к серверному предмету отладки завершается сбоем, в то время как клиентский сеанс отлаживается без проблем.

Как в отладчике точно узнать, какая среда активна?

Поскольку инструкции препроцессора, начинающиеся с символа #, обрабатываются компилятором 1С еще до непосредственного исполнения кода, мы не можем просто написать их в окне вычисления выражений (Shift+F9) для проверки. Тем не менее, у нас есть несколько надежных способов узнать текущий контекст.

Способ 1. Визуальный анализ кода в конфигураторе

Самый простой способ — обратить внимание на цветовое оформление кода непосредственно в редакторе конфигуратора во время остановки на точке останова. Конфигуратор анализирует контекст текущей сессии отладки и динамически форматирует текст:

Те ветки кода, которые не компилируются в текущем режиме (условие препроцессора ложно), окрашиваются в светло-серый (неактивный) цвет. Отладчик физически не сможет зайти в эти строки.
Те ветки кода, условия для которых истинны, отображаются стандартным черным и цветным шрифтом.

Если у одного пользователя блок под директивой #Если Сервер горит ярким цветом, а у другого — серым, значит, они запущены в принципиально разных клиентах или с разными настройками подключения отладки.

Способ 2. Проверка через «Стек вызовов» (Ctrl + Alt + C)

Когда выполнение программы прервано точкой останова, откроем окно Стек вызовов (горячие клавиши Ctrl + Alt + C). В данном окне отображается вся цепочка вызовов процедур и функций, приведшая к текущему состоянию. Обратим внимание на колонку с именами процедур:

Если в угловых скобках перед именем метода или после него указано <Сервер> — текущий код выполняется в серверном контексте (условие #Если Сервер вернет истину).
Если указано <Клиент> — код выполняется на стороне клиентского приложения.

Способ 3. Анализ окна «Подключение предметов отладки»

Давайте проанализируем, к каким процессам сейчас подключен наш конфигуратор. Для этого перейдем в меню Отладка -> Подключение...

В таблице «Подключенные предметы отладки» детально расписан тип каждого процесса. Здесь мы можем увидеть:

Тонкий клиент (клиентская часть управляемого приложения);
Толстый клиент (в зависимости от настроек запуска это может быть обычное или управляемое приложение);
Файловый сервер (серверный поток в файловой базе данных).

Если в списке подключенных предметов отсутствует «Файловый сервер», то любые точки останова на сервере будут игнорироваться.

Способ 4. Использование функций встроенного языка в Табло (Shift + F9)

Для гарантированного программного определения среды во время отладки мы можем использовать встроенные функции платформы. Откроем окно Вычислить выражение (клавиша Shift + F9) или добавим выражения в Табло.

Рассмотрим применение функции ИмяПриложения(). Она возвращает строковое системное имя запущенного клиента. Проанализируем возможные варианты:


// Введем в Табло: ИмяПриложения()
// Возможные возвращаемые значения:
// "1CV8"         - Запущен Толстый клиент (управляемое или обычное приложение)
// "1CV8C"        - Запущен Тонкий клиент
// "WebClient"    - Запущен Веб-клиент в браузере
// "COMConnection"- База запущена в режиме внешнего соединения (COM)

Для того чтобы точно определить, не запущен ли толстый клиент в режиме обычного приложения (что соответствует условию препроцессора ТолстыйКлиентОбычноеПриложение), воспользуемся функцией ТекущийРежимЗапуска(). Она возвращает системное перечисление РежимЗапускаКлиентскогоПриложения.

Рассмотрим пример кода, демонстрирующий логику этой проверки:


Режим = ТекущийРежимЗапуска();
Если Режим = РежимЗапускаКлиентскогоПриложения.Обычное Тогда
    // Это режим "ТолстыйКлиентОбычноеПриложение"
    Сообщить("Запущено обычное приложение!");
ИначеЕсли Режим = РежимЗапускаКлиентскогоПриложения.Управляемое Тогда
    // Запущено управляемое приложение (тонкий или толстый управляемый клиент)
    Сообщить("Запущено управляемое приложение!");
КонецЕсли;

Комбинируя результаты функций ИмяПриложения() и ТекущийРежимЗапуска() в окне вычисления выражений отладчика, мы можем со 100% уверенностью определить, под какими именно условиями препроцессора сейчас работает текущий сеанс 1С.