Перед предисловием
Привет из прошлого! Статья перед Вами была создана в далеком 2013 году, уже целых 6 лет прошло. Несмотря на это, тема программного изменения форм остается актуальной. Кто-то использует эти возможности для уменьшения трудозатрат на сопровождение типовых конфигураций, ведь сравнивать код проще, чем элементы формы (особенно обычные формы!). Другие просто создают универсальные механизмы для построения интерфейса. В любом случае, программное изменение форм - гибкий, эффективный способ разработки со своими достоинствами и недостатками.
И раз тема до сих пор актуальна, то поднимем ее еще раз. Немного добавив новой информации.
Предисловие
При разработке интер
фейса решений на платформе 1С:Предприятие 8.x часто возникает необходимость изменения форм программным образом. В типовых конфигурациях программная модификация форм осуществляется, например, для механизма контактной информации, который в открываемой форме создает закладку "Контактная информация" и добавляет на нее соответствующие реквизиты, связанные с открываемым объектом.
Еще одной из самых распространенных задач, где используется программное изменение форм - модификация типовых решений. Поскольку платформа не может сравнивать две формы на различие состава элементов и значений их свойств (больше относится к обычным формам, управляемые имеют больше возможностей для сравнения / объединения), то для упрощения последующего процесса обновления конфигурации рекомендуется модифицировать форму именно программным образом. Ведь модули форм сравнить возможно, в отличии от свойств их элементов.
Сегодня в статье будет идти речь о трудностях, с которыми можно столкнуться при программной модификации как управляемых, так и обычных форм. Также будет сделано небольшое сравнение среды разработки "Конфигуратор" с развитой, на мой взгляд", IDE "Visual Studio 2010" в части разработки интерфейсов.
Скучное дело
Именно так! Программное изменение формы это монотонное, скучное дело. Описывать в коде создаваемые элементы, их свойства и поведение. Практически всегда последовательность действий разработчика одинаковая: создал элемент, назначил свойства, по необходимости привязки (для обычных форм) и свойства отображения. После запустил режим 1С:Предприятие чтобы посмотреть на результат. Если в интерфейсе что-то не так, то возвращаемся обратно к коду и так далее.
Для примера сделаем в тестовой конфигурации документ "ПриходнаяНакладная", для которого добавим табличную часть "Товары" с реквизитами "Товар" и "Количество" с типами "СправочникСсылка.Товары" и "Число" соответственно.
На скриншоте выше показана структура добавленного объекта. Обратите внимание, что для документа были созданы две формы. Одна для управляемого приложения, другая для обычного. По названию не трудно догадаться какая из форм для какого режима предназначена. На следующем скриншоте Вы можете видеть форму документа "ПриходнаяНакладная" в обычном и управляемом приложении.
В данный момент формы созданы с помощью конструктора в конфигураторе. Чтобы показать насколько усложняется разработка при программном изменении формы, напишем необходимый код. Будем обрабатывать создание следующих элементов:
- Поле "Номер".
- Поле "Дата".
- Табличную часть "Товары".
- Командную панель табличной части "Товары".
В конструкторе это займет не более пяти минут! При написании же программного кода Вы можете затратить значительно время, которое не всегда учтено в назначенных для задачи сроках.
Для начала напишем программный код для создания элементов в управляемой форме документа В конечном итоге она не должна отличаться от формы, созданной до этого конструктором. Для небольшого усложнения примера добавим колонке "Количество" обработчик события "ПриИзменении", по выполнении которого пользователю будет появляться предупреждение о введенном количестве.
Так мы получили программный код, который создает элементы формы, оговоренные ранее. Весь код занял 31 строчку, причем созданный интерфейс очень простой.
Ниже представлен алгоритм для программного создания элементов на управляемой форме с привязкой к колонке "Количество" процедуры обработчика события "ПриИзменении".
Однако тут есть несколько "НО"! По сравнению с обычными формами, управляемые формы редактировать намного проще. Они являются своего рода конструктором, который сам определяет что и как должно отобразиться в пользовательском интерфейсе. Например, в управляемых формах отсутствует необходимость в установке привязок элементов как это было в обычных формах. Управляемые формы делают процесс разработки интерфейса более эффективным как с точки зрения затраченного времени разработчика, так и со стороны производительности, так как для их передачи с сервера на клиент нужно значительно меньше трафика.
Для демонстрации того, что программная работа с обычной формой сложнее, приведем алгоритм создания элементов формы, который выполнит действия аналогичные коду, написанному выше для управляемого приложения (см. следующий листинг).
Факт на лицо. Объем программного кода увеличился практически в пять раз! Время на его написание нужно существенно больше, чем в первом примере.
Очень часто можно прочитать рекомендации по модификации типовых решений, где написано, что изменение форм должно производиться программным образом, чтобы дальнейшее обновление конфигурации из официальных поставок обновлений производилось без лишних проблем. Полностью с этим согласен! Но что, если сроки по выполнению задания очень ограничены, а объем работ для модификации форм может занять чуть ли не половину времени выполнения всего задания (а то и больше)?
Сложности дальнейшей модификации
Из выше написанного вытекает следующее: даже если мы будем производить все изменения форм в типовой конфигурации, да и вообще в любой, программным образом, то рано или поздно наступит момент, когда добавление одного единственного элемента на форму станет настоящим адом! Представьте себе, что в сформированную ранее обычную форму нам нужно добавить еще одну табличную часть над уже существующей, да еще и вынести реквизиты и табличные части в отдельные закладки!
Написание программного кода для таких действий с элементами настолько усложнит алгоритм, что рано или поздно Вы откажитесь от программной модификации форм. Не согласны? Время покажет!
В принципе, платформа позволяет сравнить формы через сравнение конфигураций, но полученный результат редко можно использовать на практике. В отчете присутствует лишь информация о факте модификации, добавления элементов. Какие же свойства и как они были изменены отчет не позволяет увидеть.
Ну и что, что платформа не умеет сравнивать формы поэлементно с учетом их свойств при сравнении конфигураций? Не каждый же день обновляются формы, если что - вручную все поменяем...
Немного критики
Развитие платформы 1С:Предприятие идет с такой скоростью, что иногда складывается устойчивое ощущение того, как платформа подобна инструменту, совершенствующемуся прямо у Вас в руках! В этом нет больших минусов, ведь развитие программы в итоге идет на пользу конечному потребителю, то есть пользователю. Но вот о разработчиках похоже подзабыли!
Предлагаю посмотреть на работу с интерфейсами в "Visual Studio 2010". Создадим простое приложение WindowsForm, и добавим на форму кнопку "button1". Заголовок изменен на "Devel 1C" (см. следующий скриншот).
При этом Visual Studio автоматически (!!!) создает программный код для элементов на форме. То есть если мы пользуемся конструктором форм, IDE все равно создает программный код для каждого элемента формы, заполняет его свойства и прочее.
Код хранится в файле "<ИмяФормы>.Designer.cs", связанный с файлом самой формы. На следующем скриншоте представил часть модуля файла "Designer.cs", в которой среда разработки создает код создания элементов формы.
На мой взгляд, если бы платформа 1С:Предприятие могла таким же образом работать с созданием форм, то для разработчика это было бы намного удобней.
Помощник
Сказки сказками, но маловероятно, что фирма "1С" имеет приоритетную задачу по улучшению работы среды разработки платформы в части пользовательского интерфейса. Даже не смотря на появление EDT особого прогресса в этой части пока так и нет.
Сейчас же приходиться придумывать различного рода инструменты, позволяющие автоматизировать рутинный труд по написанию кода программного заполнения формы элементами.
В древней публикации "Помощник программного изменения формы" была попытка создать инструмент, который бы помогал формировать код для создания / изменения форм. Узнать подробную информацию и загрузить его Вы можете по ссылке. Если кратко, то обработка позволяет автоматически формировать программный код для создания элементов формы (обычной или управляемой) и устанавливать ее свойства.
Инструмент не дошел до финальной версии и до сих пор находится в глубокой альфе в виде эксперимента. Сил и времени на него так и не нашлось. Да и со временем изменил свое отношение к программной работе с формами и не пытаюсь применять его везде. Только там, где без этого никуда.
Вместо заключения
Несмотря на то, что программная работа с элементами формы не часто используется в повседневных задачах, использование этого механизма позволяет создавать очень гибкие и эффективные интерфейсы, а также проводить модификацию типовых конфигураций с наименьшими проблемами при последующих обновлениях.
Платформа 1С:Предприятие 8.x не имеет собственных инструментов в помощь разработчику для программной работы с формой и ее элементами. Все, что есть - это синтаксис помощник с описанием доступных свойств элементов и описание методов программной работы. Весь рутинный труд по описанию каждого свойства элементов в программном коде ложится на плечи программиста.
Остается надеяться, что среда разработки платформы 1С:Предприятие 8.x будет развиваться и вбирать в себя все лучшее современных IDE. А пока на помощь Вам могут придти инструменты из списка ниже.
Другие ссылки
Интересные инструменты для работы с формами:
