Разработка и Конфигурация · 12 мин
Неуправляемые формы 1С: что это и когда они применяются
Неуправляемые формы 1С: что это такое, чем отличаются от управляемых, где встречаются обычные формы и стоит ли создавать новые. Разбор для разработчиков.
Неуправляемая форма в 1С — это форма, внешний вид и поведение которой разработчик полностью описывает сам: расположение элементов, их размеры, привязки и логику обработчиков. Такие формы появились в платформе до версии 8.2 и до сих пор встречаются в конфигурациях, работающих в режиме обычного приложения, а также в старых решениях, которые не переводили на управляемый интерфейс.
Ключевое отличие от управляемых форм — отсутствие автоматической компоновки. В управляемой форме платформа сама решает, как отобразить элементы на экране, и разработчик лишь декларирует структуру. В неуправляемой форме каждый элемент размещается вручную в редакторе формы, а его положение фиксируется координатами и привязками к границам.
Понимание этого механизма нужно не только тем, кто поддерживает старые конфигурации. Неуправляемые формы встречаются при доработке типовых решений, при анализе чужого кода и при выборе архитектуры новых доработок. Ниже разобрано устройство таких форм, их отличия от управляемых, типичные задачи и ограничения.
Что такое неуправляемая форма и как она устроена
Неуправляемая (обычная) форма состоит из трёх частей: визуального представления в редакторе форм, модуля формы с кодом на встроенном языке и связанных с формой данных (реквизитов). В редакторе разработчик перетаскивает элементы — поля ввода, кнопки, табличные поля, надписи — и задаёт их свойства: координаты, размеры, привязки при изменении размера окна.
Данные в обычной форме привязываются к элементам напрямую. Табличное поле связано с таблицей значений или табличной частью объекта, поле ввода — с реквизитом. Изменение данных в элементе сразу отражается на связанном объекте, без промежуточных механизмов сериализации, характерных для управляемого режима.
Модуль обычной формы исполняется целиком на клиенте. Это значит, что в нём доступны любые операции, включая прямую работу с файловой системой, COM-объектами и модальные окна. Такая свобода упрощала разработку в своё время, но стала причиной многих архитектурных проблем при масштабировании решений.
Чем неуправляемые формы отличаются от управляемых
Управляемые формы появились в платформе 8.2 вместе с режимом управляемого приложения. Их главная идея — декларативность: разработчик описывает, какие данные и команды должны быть на форме, а платформа сама строит интерфейс под конкретный клиент (тонкий, толстый, веб-клиент, мобильный клиент).
| Критерий | Неуправляемая форма | Управляемая форма |
|---|---|---|
| Размещение элементов | Вручную, по координатам | Автоматически, по структуре |
| Исполнение кода | Только на клиенте | Клиент + сервер, директивы компиляции |
| Веб-клиент | Не поддерживается | Поддерживается |
| Модальные окна | Работают | Запрещены (только асинхронные вызовы) |
| Редактор формы | Визуальный, «как на экране» | Дерево элементов и реквизитов |
Практическое следствие различий: обычная форма выглядит одинаково везде, где она вообще может быть открыта, но круг таких клиентов ограничен. Управляемая форма адаптируется под устройство, но требует от разработчика дисциплины — разделения клиентского и серверного кода, отказа от модальности.
Сравнение вариантов
Подходит для поддержки старых конфигураций в режиме обычного приложения. Ограничение: не работает в веб-клиенте и мобильном клиенте.
Стандарт для современных конфигураций: работает во всех клиентах, поддерживает такси-интерфейс. Ограничение: требует переработки логики под клиент-серверную модель.
Где неуправляемые формы встречаются на практике
Основной источник обычных форм — конфигурации, созданные на платформе 8.0 и 8.1, а также решения, которые после перехода на 8.2 и выше продолжили работать в режиме обычного приложения. Типовые примеры — старые версии «Управления торговлей», «Бухгалтерии» редакций 1.6 и 2.0, отраслевые и самописные конфигурации.
Второй сценарий — смешанный режим. Конфигурация может быть переведена на управляемое приложение, но отдельные обработки и отчёты остались с обычными формами. В таком случае платформа откроет обычную форму, если режим совместимости это позволяет, но внешний вид и поведение будут заметно отличаться от остального интерфейса.
Третий сценарий — внешние обработки, которые разработчики писали «по старинке». При открытии такой обработки в конфигурации с управляемым интерфейсом пользователь видит окно другого стиля, что часто вызывает вопросы и жалобы.
Ограничения и риски работы с обычными формами
Главное ограничение — неуправляемые формы не работают в веб-клиенте и мобильном клиенте. Если в планах компании публикация базы на веб-сервере или доступ с планшетов, обычные формы становятся блокирующим фактором: их придётся переписывать.
Второй риск — модальность. Обычные формы активно используют модальные окна (ОткрытьМодально(), Вопрос() с блокировкой), а в новых версиях платформы модальность по умолчанию запрещена. При обновлении платформы старый код может перестать работать без изменения настроек совместимости.
Третья проблема — вся логика исполняется на клиенте. В клиент-серверном варианте это приводит к лишним вызовам, медленной работе на слабых каналах и невозможности использовать серверные ресурсы для тяжёлых операций. Запросы и вычисления, которые в управляемой форме выполняются на сервере, в обычной идут с рабочего места пользователя.
Как определить тип формы в конфигураторе
Проверить, какая форма перед вами, можно несколькими способами. Самый быстрый — открыть форму объекта в конфигураторе и посмотреть на редактор. У обычной формы редактор визуальный: вы видите макет окна с элементами, которые можно перетаскивать мышью. У управляемой — дерево элементов слева и список реквизитов справа, без «картинки» формы.
Второй признак — структура модуля. В модуле обычной формы нет директив компиляции (&НаКлиенте, &НаСервере), потому что весь код клиентский. Если директивы есть — форма управляемая.
- 1Откройте конфигуратор и найдите нужный объект (документ, справочник, обработку).
- 2Раскройте ветку «Формы» и откройте основную форму.
- 3Посмотрите на вид редактора: визуальный макет — обычная форма, дерево элементов — управляемая.
- 4Откройте модуль формы и проверьте наличие директив &НаКлиенте / &НаСервере.
- 5Проверьте в свойствах конфигурации основной режим запуска и режим совместимости.
Третий способ — программный. В пользовательском режиме тип формы можно косвенно определить по внешнему виду: обычные формы открываются в отдельных окнах со старым стилем элементов, тогда как управляемые встраиваются в интерфейс «Такси» или в рабочее окно приложения.
Стоит ли создавать новые неуправляемые формы
Для новых разработок обычные формы создавать не следует. Платформа давно ориентирована на управляемое приложение, и новые механизмы (расширения, мобильный клиент, веб-доступ) рассчитаны именно на него. Новая обычная форма — это накопление технического долга, который рано или поздно придётся погашать переписыванием.
Исключение — точечная доработка конфигурации, которая целиком работает в обычном приложении и не планирует миграцию. В такой ситуации добавление управляемой формы невозможно или бессмысленно: она всё равно будет открываться в старом стиле. Здесь разумно следовать существующей архитектуре, но важно зафиксировать, что это осознанное решение, а не привычка.
Как выбрать действие
Типичные ошибки при работе с обычными формами
Самая частая ошибка — попытка открыть обычную форму методами управляемого интерфейса или наоборот. Метод ОткрытьФорму() работает с управляемыми формами, тогда как обычные открываются через ПолучитьФорму() и Открыть(). Смешение подходов приводит к ошибкам времени выполнения.
Вторая ошибка — перенос кода из обычной формы в управляемую «как есть». Клиентские обращения к данным, модальные вызовы и работа с табличными полями в управляемой форме не работают: там другие типы элементов (таблица формы вместо табличного поля) и другая модель доступа к данным.
Третья ошибка — размещение бизнес-логики в обработчиках элементов формы. В обычных формах это было массовой практикой, но она делает поведение объекта зависимым от интерфейса: при обмене данными или программном проведении документа логика не срабатывает. Правильное место для такой логики — модуль объекта.
Как проверить результат после доработки
После изменения обычной формы проверяйте не только её открытие, но и поведение при изменении размеров окна: элементы с неверными привязками «уезжают» или перекрывают друг друга. Проверьте работу обработчиков на пустых и заполненных данных — в обычных формах часто встречаются обращения к строкам таблицы без проверки их наличия.
Как проверить результат
Форма открывается без ошибок в нужном режиме запуска
Ошибка компиляции модуля или «Метод не обнаружен»
Элементы растягиваются и остаются на своих местах
Элементы наезжают друг на друга или исчезают за границей
Данные сохраняются, обязательные поля проверяются
Данные элемента формы не попадают в объект
Объект корректно создаётся и проводится программно
Логика срабатывает только при ручном вводе через форму
Если доработка касается конфигурации со смешанными формами, дополнительно протестируйте открытие объекта из всех точек входа: из списка, из отчёта, из другой формы. Обычные и управляемые формы по-разному обрабатывают параметры открытия, и часть сценариев может молча не работать.
Что важно запомнить
Неуправляемая форма — наследие обычного приложения: ручное размещение элементов, весь код на клиенте, никакого веб-клиента. Поддерживайте такие формы там, где они уже есть, но новые создавайте только управляемыми.
Частые вопросы о неуправляемых формах
Можно ли открыть обычную форму в веб-клиенте?
Нет. Обычные формы технически не поддерживаются веб-клиентом и мобильным клиентом. Если доступ через браузер обязателен, форму нужно пересоздавать как управляемую с переработкой логики под клиент-серверную модель.
Почему в конфигураторе два редактора форм с разным видом?
Потому что платформа поддерживает оба типа форм. Визуальный редактор с перетаскиванием элементов — для обычных форм, редактор с деревом элементов и реквизитов — для управляемых. Тип редактора определяется типом формы, заданным при её создании.
Что будет с обычными формами при обновлении платформы?
Сами формы продолжат работать, если сохранён совместимый режим запуска и разрешена модальность. Риски возникают при смене режима совместимости и отказе от модальных вызовов — тогда старый код потребует доработки. Перед обновлением проверяйте свойства конфигурации и тестируйте на копии базы.
Как быстро найти все обычные формы в конфигурации?
Надёжный способ — выгрузить конфигурацию в файлы и поискать по типу форм в служебных файлах выгрузки. Также можно воспользоваться штатным поиском по конфигурации: у обычных форм в модуле отсутствуют директивы компиляции, что позволяет отфильтровать их поиском по текстам модулей.
Нужно ли переписывать обычные формы, если всё работает?
Если конфигурация используется только в толстом и тонком клиенте и планов на веб-доступ нет, срочной необходимости в переписывании нет. Но при любой крупной доработке формы стоит оценить стоимость её перевода на управляемый вариант — часто это дешевле, чем наращивание старого кода.
Чем заменить модальные окна из обычных форм?
В управляемых формах вместо модальных вызовов используются асинхронные методы с описанием оповещения: ПоказатьВопрос(), ОткрытьФорму() с обработчиком закрытия, НачатьПомещениеФайла() и аналоги. Логика после ответа пользователя переносится в отдельную процедуру-обработчик оповещения.