Как разобраться в отличиях обычных и управляемых форм в 1С и настроить их работу в разных клиентах?

← На главную

Переход разработчика от современных конфигураций на управляемых формах (таких как «Управление торговлей 11» или «Бухгалтерия предприятия 3.0») к поддержке устаревших систем (например, «Управление производственным предприятием 1.3») часто вызывает ступор. Открывая старую конфигурацию, специалист обнаруживает формы без привычных директив компиляции &НаКлиенте и &НаСервере, а поведение программы в тонком и толстом клиентах начинает казаться хаотичным.

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

Различие в подходах к проектированию: Обычные vs Управляемые формы

Для того чтобы успешно работать со старыми конфигурациями, нам необходимо полностью перестроить мышление. Главная ошибка начинающих разработчиков — попытка применить логику управляемого приложения к обычным формам.

Проанализируем принципиальные различия в их проектировании:

Обычные формы (визуальное позиционирование): Верстка элементов здесь происходит «по пикселям». Разработчик вручную размещает каждый реквизит, кнопку или таблицу на холсте формы, а адаптация под разные разрешения экрана настраивается с помощью сложных правил взаимных «привязок» границ элементов. Вся бизнес-логика выполняется в едином контексте, поэтому в модуле формы отсутствуют директивы компиляции.
Управляемые формы (декларативное описание): Разработчик не рисует форму вручную. Вместо этого создается логическая структура элементов (группы, колонки, страницы), а платформа самостоятельно отрисовывает и масштабирует интерфейс под текущее разрешение экрана и операционную систему. Здесь строго разделены данные формы и данные базы данных, а программный код жестко разграничен директивами компиляции.

Посмотрим на пример кода, демонстрирующий разницу в подходах к обработке событий изменения данных:

В управляемой форме мы обязаны явно разделять контекст выполнения:


&НаКлиенте
Процедура КоличествоПриИзменении(Элемент)
    // Клиентская логика (например, интерактивный пересчет суммы)
    РассчитатьСуммуНаСервере();
КонецПроцедуры

&НаСервере
Процедура РассчитатьСуммуНаСервере()
    // Серверная логика (запросы к базе данных, обращение к объектной модели)
    // Доступны серверные типы данных, например, СправочникОбъект или ДокументОбъект
КонецПроцедуры

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


Процедура КоличествоПриИзменении(Элемент)
    // Весь код пишется в одной процедуре без директив.
    // Прямо отсюда можно делать тяжелые запросы к СУБД или обращаться к серверным объектам.
    Сумма = Количество * Цена;
КонецПроцедуры

Тонкий и Толстый клиент: развенчиваем мифы о режимах запуска

Среди разработчиков 1С распространено опасное заблуждение: якобы обычные формы могут работать только в толстом клиенте, а управляемые — только в тонком. Давайте разберем реальную картину взаимодействия типов форм и режимов запуска.

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

Рассмотрим важный нюанс: когда мы запускаем управляемую форму в режиме «Толстый клиент — управляемое приложение», директивы компиляции &НаКлиенте и &НаСервере продолжают строго соблюдаться платформой. Код, помеченный директивой &НаКлиенте, выполняется в клиентском контексте, и в нем по-прежнему запрещено напрямую обращаться к серверным типам данных (таким как Запрос, ТаблицаЗначений или прикладные объекты базы данных). Разница лишь в том, что физически оба контекста выполняются в рамках одного процесса операционной системы на компьютере пользователя, исключая сетевые задержки при серверных вызовах.

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

Автогенерация управляемых форм и ее главная опасность

Что произойдет, если запустить систему (например, УПП) в режиме Тонкого клиента и попытаться открыть документ, для которого разработчиками создана только обычная форма?

Платформа автоматически сгенерирует управляемую форму «на лету» на основе метаданных прикладного объекта. Пользователь увидит стандартное расположение реквизитов и табличных частей. Однако здесь кроется критическая ловушка для разработчика.

При автогенерации управляемой формы весь программный код, написанный в модуле обычной формы, полностью игнорируется!

Это означает следующее:

Ни один обработчик событий (при открытии, при изменении реквизитов, перед записью) не будет выполнен.
Алгоритмы автоматического расчета цен, проверки заполнения реквизитов и динамического скрытия полей не сработают.
Пользователь получит «пустой» визуальный шаблон, заполнение данных в котором может привести к нарушению целостности базы данных и ошибкам проведения документов.

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

Настройка «Использовать обычные формы в управляемом приложении»

Для постепенного перевода крупных систем с обычного интерфейса на управляемый разработчики платформы предусмотрели свойство в корне конфигурации — Использовать обычные формы в управляемом приложении.

Давайте разберем, как работает эта опция. При ее включении система позволяет в рамках одного сеанса сочетать работу как с управляемым интерфейсом, так и со старыми обычными формами. Но помните о ключевом ограничении: данная схема работает только при запуске в режиме Толстого клиента. Попытка открыть обычную форму в Тонком или Веб-клиенте все равно завершится неудачей или автоматической генерацией «пустой» управляемой формы.

Последствия включения режима интерфейса «Такси» в старых конфигурациях

Иногда у разработчиков возникает соблазн снять конфигурацию (например, УПП) с поддержки, отключить режим совместимости и принудительно включить современный интерфейс «Такси». На первый взгляд это может показаться безопасным косметическим изменением, однако на практике такое решение ведет к катастрофическим последствиям для стабильности системы.

Выясним основные причины, почему нельзя бездумно включать режим «Такси» в старых прикладных решениях:

Критический конфликт модальности: Современный интерфейс «Такси» полностью ориентирован на асинхронную работу без использования модальных окон. Конфигурации уровня УПП буквально перенасыщены синхронными и модальными методами (такими как Вопрос(), Предупреждение() или ОткрытьФормуМодально()). Принудительное отключение режима совместимости приведет к тому, что программа начнет аварийно завершать работу в коде при любой попытке интерактивного взаимодействия с пользователем. Потребуется колоссальный ручной рефакторинг всего программного кода.
Визуальный хаос и наложение элементов: Обычные формы физически не могут интегрироваться внутрь плиточного интерфейса «Такси». При открытии они будут отображаться в виде классических окон операционной системы Windows поверх современного интерфейса. Более того, увеличенные шрифты и элементы управления «Такси», созданные для сенсорных экранов, исказят верстку старых управляемых форм: поля начнут наползать друг на друга, а важные таблицы перестанут помещаться в границы экрана.

Посмотрим на пример перевода синхронного (модального) вызова диалогового окна в асинхронный формат, который обязателен для полноценной работы в режиме «Такси»:

Старый небезопасный вариант кода, приводящий к ошибке в режиме без совместимости:


Режим = РежимДиалогаВопрос.ДаНет;
Ответ = Вопрос("Вы уверены, что хотите провести документ?", Режим, 0);
Если Ответ = КодВозвратаДиалога.Да Тогда
    ПровестиДокумент();
КонецЕсли;

Новый безопасный асинхронный вариант кода с использованием описания оповещения:


&НаКлиенте
Процедура ЗапроситьПодтверждение()
    Режим = РежимДиалогаВопрос.ДаНет;
    Оповещение = Новый ОписаниеОповещения("ПослеВопросаОПроведении", ЭтотОбъект);
    ПоказатьВопрос(Оповещение, "Вы уверены, что хотите провести документ?", Режим);
КонецПроцедуры

&НаКлиенте
Процедура ПослеВопросаОПроведении(Результат, ДополнительныеПараметры) Экспорт
    Если Результат = КодВозвратаДиалога.Да Тогда
        ПровестиДокумент();
    КонецЕсли;
КонецПроцедуры

Подведем итоги

Для успешной и стабильной работы с формами в платформе 1С необходимо четко разделять понятия режимов запуска клиентов и типов интерфейсных форм. Если вам приходится дорабатывать старую систему, использующую обычные формы, выполняйте разработку строго в рамках концепции обычного приложения под Толстым клиентом. Попытки быстро «скрестить» старый код с Тонким клиентом или интерфейсом «Такси» без тотальной переработки всей архитектуры прикладного решения гарантированно приведут к программным сбоям и потере стабильности базы данных.