Неуправляемые формы 1С: что это такое и когда они применяются

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

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

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

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

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

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

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

Чем неуправляемые формы отличаются от управляемых

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

Второе отличие — модель выполнения кода. Управляемая форма строго разделяет клиентские и серверные процедуры директивами компиляции («&НаКлиенте», «&НаСервере») и передаёт данные между ними сериализацией. В неуправляемой форме такого разделения нет: весь модуль исполняется в одном контексте, и прямой вызов запроса из обработчика кнопки — нормальная практика.

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

Где неуправляемые формы встречаются на практике

Основной источник неуправляемых форм — конфигурации, созданные на платформе 8.1 и 8.2 и переведённые на 8.3 без переписывания интерфейса. Типовые решения тех лет (ранние редакции «Управления торговлей», «УПП», отраслевые конфигурации) содержат сотни обычных форм. Если система запускается в режиме обычного приложения, эти формы продолжают корректно работать.

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

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

Ограничения и риски работы с неуправляемыми формами

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

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

Третий риск — производительность при сетевой работе. Поскольку обычная форма обращается к данным напрямую и часто, при работе через медленный канал (VPN, удалённый офис) интерфейс заметно «подвисает»: каждый запрос идёт с клиента на сервер отдельно, без пакетной оптимизации, характерной для управляемых форм.

Как создать и доработать неуправляемую форму

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

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

Типичная доработка — добавление реквизита объекта на форму. Последовательность: добавить реквизит в метаданные, открыть форму, разместить поле ввода, связать его с данными через свойство «Данные», проверить обновление объекта при записи. Если поле не связано с данными, значение будет отображаться, но не сохранится.

1. 1
   Добавьте реквизит в объект метаданных и обновите конфигурацию базы данных на тестовой копии
2. 2
   Откройте обычную форму в конфигураторе и разместите новое поле ввода
3. 3
   В палитре свойств свяжите поле с реквизитом через свойство «Данные»
4. 4
   Настройте привязки элемента, чтобы форма не разъезжалась при изменении размера
5. 5
   Проверьте в пользовательском режиме: ввод значения, запись объекта, повторное открытие формы

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

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

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

Сравнение вариантов действий со старыми формами

Оставить как есть

Подходит, если все пользователи на толстом клиенте и доработки минимальны; риск — накопление технического долга

Поэтапная миграция

Оптимально для больших конфигураций: сначала массовые формы, затем остальные; требует плана и тестирования

Полное переписывание

Оправдано при смене платформенного режима или переходе на веб-клиент; самый дорогой, но окончательный вариант

Типичные ошибки при работе с неуправляемыми формами

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

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

Как проверить результат доработки

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

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

Контрольные точки

Как проверить результат

Открытие формы

Норма

Форма открывается в обычном приложении без ошибок

Тревожный признак

Ошибка компиляции модуля или пустое окно

Сохранение данных

Норма

Введённые значения записываются и видны при повторном открытии

Тревожный признак

Поле очищается после записи — нет связи с данными

Изменение размера окна

Норма

Элементы смещаются по привязкам, ничего не накладывается

Тревожный признак

Поля наезжают друг на друга или исчезают

Права пользователя

Норма

Форма работает под типовой ролью пользователя

Тревожный признак

Ошибки доступа к реквизитам у рядовых пользователей

Частые вопросы о неуправляемых формах 1С

Можно ли открыть обычную форму в тонком клиенте?

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

Почему внешняя обработка не открывается в 1С?

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

Можно ли автоматически конвертировать обычную форму в управляемую?

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

Устарели ли обычные формы окончательно?

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

Что будет с обычными формами при обновлении платформы?

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

Стоит ли новичку изучать разработку обычных форм?

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