Управляемая форма 1С: что это и как с ней работать

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

Ключевая особенность — разделение кода на клиентскую и серверную части. Любое обращение к данным базы, запросам или объектам возможно только на сервере, а на клиенте выполняется лишь логика интерфейса: проверка введённых значений, управление видимостью элементов, показ предупреждений. Это меняет привычный подход к написанию обработчиков и требует явного понимания, где именно выполняется каждый фрагмент кода.

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

Как устроена управляемая форма

Формально управляемая форма состоит из четырёх частей: реквизитов (данные формы), элементов (визуальное дерево), команд (действия пользователя) и модуля формы (программный код). Реквизиты — это «транспорт» данных между клиентом и сервером: именно их содержимое передаётся при каждом серверном вызове. Элементы формы привязываются к реквизитам через свойство «ПутьКДанным», и платформа автоматически синхронизирует отображение с данными.

Основной реквизит формы — «Объект» — появляется у форм, привязанных к данным: документа, справочника, записи регистра. Он представляет данные объекта в виде значения типа «ДанныеФормыСтруктура», а не как реальный объект базы данных. Поэтому конструкция вида Объект.Провести() в управляемой форме недоступна напрямую — сначала нужно преобразовать данные формы в объект через РеквизитФормыВЗначение("Объект").

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

Отличия от обычных форм

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

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

Директивы компиляции и серверные вызовы

Каждая процедура и функция в модуле управляемой формы помечается одной из директив: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, &НаКлиентеНаСервереБезКонтекста. Директива определяет, где код скомпилируется и выполнится. Если директиву не указать, платформа по умолчанию считает метод серверным, что часто становится источником ошибок.

Директива &НаСервереБезКонтекста означает, что метод не имеет доступа к реквизитам формы — туда нельзя передать «ЭтаФорма». Зато такие вызовы быстрее: платформе не нужно сериализовать и передавать все данные формы на сервер и обратно. Правило простое: если методу не нужны данные формы — делайте его серверным без контекста.

&НаКлиенте
Процедура РассчитатьСумму(Команда)
	РассчитатьСуммуНаСервере(Объект.Ссылка);
КонецПроцедуры

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

Каждый переход «клиент → сервер» — это сетевой вызов с передачей данных. Десять серверных вызовов в цикле превратят форму в медленную даже в локальной сети, а через интернет сделают работу невозможной. Проектируйте обработчики так, чтобы один пользовательский сценарий обходился одним-двумя серверными вызовами.

Основные события формы и порядок работы с ними

Жизненный цикл формы начинается с событий ПриСозданииНаСервере (сервер, форма ещё не показана, можно заполнить реквизиты и настроить элементы) и ПриОткрытии (клиент, форма уже отображается, доступны интерактивные действия). Частая ошибка — пытаться в ПриСозданииНаСервере показать пользователю вопрос или предупреждение: на сервере интерактивные вызовы недоступны.

Для форм объектов важны события записи: ПередЗаписью и ПослеЗаписи на клиенте, ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере на сервере. Проверку заполнения, требующую обращения к базе, выполняйте в ОбработкаПроверкиЗаполненияНаСервере — так вы избежите лишних вызовов и получите штатный механизм сообщений, привязанных к полям.

1. 1
   Создайте команду формы на закладке «Команды» в редакторе формы
2. 2
   Перетащите команду на командную панель или кнопку в дереве элементов
3. 3
   В свойстве «Действие» укажите имя процедуры — платформа создаст заготовку с директивой &НаКлиенте
4. 4
   Если нужны данные из базы — вызовите из клиентского обработчика серверный метод
5. 5
   Проверьте работу в тонком и веб-клиенте, если оба используются

Условное оформление и динамическое управление видимостью

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

Видимость элементов тоже лучше привязывать к функциональным опциям и условному оформлению, а не переключать в каждом обработчике. Если всё же нужно программное управление, делайте это в одном методе вида «УстановитьВидимостьДоступность()» и вызывайте его из всех мест, где меняются влияющие данные. Разбросанные по модулю присвоения Элементы.Поле.Видимость = Ложь быстро приводят к противоречивому состоянию интерфейса.

Типичные ошибки и ограничения

Самая распространённая ошибка новичков — попытка обратиться к объекту базы данных из клиентского кода: Объект.Ссылка.Проведен в клиентском контексте выглядит безобидно, но любое разыменование ссылки, кроме чтения реквизитов, уже переданных на клиент, требует сервера. Вторая типичная проблема — использование модальных методов (Вопрос, ОткрытьЗначение) без учёта режима отказа от модальности: в типовых конфигурациях и веб-клиенте нужно применять асинхронные аналоги ПоказатьВопрос, ПоказатьВводЗначения с описанием оповещения.

Ограничения, о которых стоит помнить: на клиенте недоступны запросы, менеджеры объектов, прямая работа с транзакциями; в веб-клиенте дополнительно ограничена работа с файловой системой без расширения работы с файлами; методы &НаСервереБезКонтекста не видят реквизиты формы. Эти рамки нельзя «обойти» — их нужно учитывать при проектировании.

Когда управляемая форма не нужна

Не всякий интерфейс в 1С обязан быть управляемой формой. Простые диалоги выбора реализуются штатными методами (ПоказатьВводЗначения, ВыбратьИзСписка), отчёты на СКД часто вообще не требуют собственной формы — достаточно настроек схемы компоновки. Создавать отдельную форму стоит, когда нужна нестандартная компоновка, собственная логика проверки или интерактивные сценарии, не покрываемые типовыми механизмами.

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

Частые вопросы