Как перенести дизайн обычной формы в управляемую: методы автоматизации и технические нюансы

← На главную

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

Различие принципов построения интерфейса

Прежде чем приступать к конвертации, проанализируем ситуацию: почему нельзя просто «скопировать и вставить» элементы? Главная причина заключается в принципиально разной логике позиционирования:

Обычные формы: Используют абсолютное позиционирование. Каждый виджет имеет жесткие координаты Лево (Left), Верх (Top), Ширина (Width) и Высота (Height).
Управляемые формы: Используют потоковое позиционирование. Элементы выстраиваются в иерархию групп (вертикальных и горизонтальных), а их реальное положение на экране определяет движок платформы в зависимости от разрешения монитора и настроек видимости.

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

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

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

Обычные формы при выгрузке сохраняются в подкаталоге Forms в бинарном формате с расширением .bin. Внутри этого файла данные упакованы в структуру, напоминающую результат функции ЗначениеВСтрокуВнутр(). Для работы с ними напрямую потребуется декомпилятор или использование 1С:EDT.

Управляемые формы, напротив, выгружаются в чистый и понятный XML. Рассмотрим пример структуры такого файла для поля ввода:


<ChildItems>
    <InputField name="Автомобиль" id="1">
        <DataPath>Объект.Автомобиль</DataPath>
        <ContextMenu name="АвтомобильКонтекстноеМеню" id="2"/>
        <ExtendedTooltip name="АвтомобильРасширеннаяПодсказка" id="3"/>
    </InputField>
</ChildItems>

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

Метод 1: Программное создание элементов «на лету»

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

Сначала мы создаем структуру-описание, куда помещаем все важные свойства (имя, тип, путь к данным, заголовок). Затем в контексте управляемой формы используем метод Элементы.Добавить(). Посмотрим на пример кода для генерации полей:


// Пример упрощенного алгоритма переноса
Для Каждого ЭлементОФ Из ЭтаФорма.ЭлементыФормы Цикл
    Если ТипЗнч(ЭлементОФ) = Тип("ПолеВвода") Тогда
        НовыйЭлемент = Элементы.Добавить(ЭлементОФ.Имя, Тип("ПолеФормы"), РодительскаяГруппа);
        НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
        НовыйЭлемент.ПутьКДанным = "Объект." + ЭлементОФ.Данные;
        НовыйЭлемент.Заголовок = ЭлементОФ.Подсказка;
    КонецЕсли;
КонецЦикла;

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

Метод 2: Конвертация через деструктивный анализ XML

Если нам лень писать полноценный генератор кода, мы можем воспользоваться методом «подшаманивания» XML. Для этого выполним следующие действия:

Создадим «пустую» управляемую форму в конфигураторе.
Выгрузим конфигурацию в файлы (через меню Конфигурация — Разработка конфигурации — Выгрузить конфигурацию в файлы...).
Найдем XML-файл нашей формы.
Напишем скрипт (на 1С или любом другом языке), который распарсит свойства элементов из ОФ и сформирует узлы <ChildItems> для файла управляемой формы.
Загрузим измененные файлы обратно в конфигурацию.

Этот путь позволяет массово переносить идентификаторы кнопок и привязки к реквизитам, что избавит от опечаток при ручном вводе. Однако позиционирование (группировку) всё равно придется дорабатывать «напильником» в визуальном редакторе.

Особенности логики событий и данных

Проанализируем ситуацию с обработчиками событий. Автоматически перенести код модулей практически невозможно из-за смены парадигмы «Клиент-Сервер». В обычных формах код часто выполняется «вперемешку». В управляемых формах нам жестко навязывают директивы &НаКлиенте и &НаСервере.

Рассмотрим специфику работы с данными:

В ОФ основным объектом была сама форма и ЭтотОбъект.
В УФ данные формы отделены от данных объекта. Мы работаем с типом ДанныеФормыСтруктура (обычно реквизит Объект).
При конвертации дизайна крайне важно сразу прописывать правильный DataPath (ПутьКДанным), иначе элементы будут пустыми.

Практические советы по оптимизации процесса

Выясним, стоит ли игра свеч. Опыт многих разработчиков показывает, что на средних формах ручная перерисовка в УФ оказывается быстрее, чем написание и отладка конвертера. Но для «тяжеловесных» форм со сложными табличными частями (например, 50+ колонок) автоматизация переноса именно состава элементов и их имен дает огромный выигрыш.

Рекомендации при конвертации:

Не пытайтесь воссоздать дизайн «пиксель в пиксель». Используйте группы: Группа — Горизонтальная для выравнивания меток и полей в одну строку.
Используйте Автозаголовок. В УФ это работает гораздо чище, чем отдельные надписи (Labels) в ОФ.
Командные панели в УФ должны быть привязаны к форме или таблицам. В ОФ кнопки часто «плавали» сами по себе — в УФ их лучше перенести в командный интерфейс.
Учитывайте асинхронность. Если в ОФ у вас были модальные вызовы (например, Вопрос()), дизайн кнопок может измениться в сторону использования оповещений.

Таким образом, полноценного «магического» конвертера «ОФ в УФ», который нажал и готово, не существует в публичном доступе именно из-за различий в UI-логике. Однако, используя программный перебор ЭлементыФормы и генерацию XML-описаний, мы можем автоматизировать 70-80% механической работы по переносу реквизитов, оставляя себе только творческую часть — проектирование удобного современного интерфейса.