Формы. Трудности программной работы









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

Перед предисловием

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

 

 Это информация из старого блога DevelPlatform.ru

И раз тема до сих пор актуальна, то поднимем ее еще раз. Немного добавив новой информации.

Предисловие

При разработке интерфейса решений на платформе 1С:Предприятие 8.x часто возникает необходимость изменения форм программным образом. В типовых конфигурациях программная модификация форм осуществляется, например, для механизма контактной информации, который в открываемой форме создает закладку "Контактная информация" и добавляет на нее соответствующие реквизиты, связанные с открываемым объектом.

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

Сегодня в статье будет идти речь о трудностях, с которыми можно столкнуться при программной модификации как управляемых, так и обычных форм. Также будет сделано небольшое сравнение среды разработки "Конфигуратор" с развитой, на мой взгляд", IDE "Visual Studio 2010" в части разработки интерфейсов.

Скучное дело

Именно так! Программное изменение формы это монотонное, скучное дело. Описывать в коде создаваемые элементы, их свойства и поведение. Практически всегда последовательность действий разработчика одинаковая: создал элемент, назначил свойства, по необходимости привязки (для обычных форм) и свойства отображения. После запустил режим 1С:Предприятие чтобы посмотреть на результат. Если в интерфейсе что-то не так, то возвращаемся обратно к коду и так далее.

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

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

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

  1. Поле "Номер".
  2. Поле "Дата".
  3. Табличную часть "Товары".
  4. Командную панель табличной части "Товары".

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

Для начала напишем программный код для создания элементов в управляемой форме документа  В конечном итоге она не должна отличаться от формы, созданной до этого конструктором. Для небольшого усложнения примера добавим колонке "Количество" обработчик события "ПриИзменении", по выполнении которого пользователю будет появляться предупреждение о введенном количестве.

Так мы получили программный код, который создает элементы формы, оговоренные ранее. Весь код занял 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. А пока на помощь Вам могут придти инструменты из списка ниже.

 

 А что можете сказать Вы?

Другие ссылки

Интересные инструменты для работы с формами:

21 Comments

  1. ids79

    Интересный материал, спасибо.

    Насчет приоритетов фирмы 1С, у меня часто складывается такое впечатление, что они стремятся не то что упростить, а усложнить разработку и доработку своих продуктов.

    Вот взять конфигурации для сравнения: УТ 10.3 и УТ 11, ЗУП 2.5 и ЗУП 3.1.

    Да, возможностей больше, но сложность доработки возросла в кубе как минимум. Объем кода увеличился чуть ли не в 10 раз.

    Не знаю уж с чем это связано, но факты на лицо.

    А взять какую-нибудь конфигурацию 7.7, там вообще не так много было документов, в модуле которых было больше 1000 строк кода.

    А сейчас что…

    Reply
  2. MVK80

    (0), Юрий, этот инструмент должен быть однозначно, на мой взгляд, в интересных инструментах в статье: Генерация кода управляемой формы (декомпиляция элементов)

    Reply
  3. acanta

    (1) в 7ке был меньше словарный запас. При желании весь синтакс помощник 7ки можно было перевести. Проблема в локализации метаданных и кода для поддержки и разработки местными специалистами.

    Reply
  4. ids79

    Еще вот хорошая статья на тему программного создания элементов форм.

    Reply
  5. YPermitin

    (2) Точно!

    Я совсем забыл про эту публикацию. «Лайк, репост» и добавил ссылку на нее в свою статью.

    Благодарю!

    Reply
  6. YPermitin

    (4) Да, тоже читал. Ссылку также добавил.

    Лайк и репост уже давно там оставил 🙂

    Reply
  7. YPermitin

    (1) спасибо на добром слове!

    Reply
  8. ZloyProger

    Очередная благодарность автору) Когда только начал работать с управляемыми формами наивно полагал — что вот оно счастье, но оказалось что форма управляется кем угодно, но не программистом 🙂 (может и слишком громко сказано и возможно я не всё ещё научился готовить, бесспорно за один уход от привязок (брр.. вспомню вздрогну этот ад обычных форм и малопонятные, труднодиагностириуемые глюки с ними) можно неистово плюсовать, но маловато! маловато! © Падал прошлогодний снег), но вот здеся описал прямо в статье суть проблемы с управлением шириной колонок при программном создании, красивого и универсального решения которой пока так и не нашел( Буду признателен за идеи)

    Reply
  9. YPermitin

    (8) спасибо)

    Но то что мало это да. Тема очень большая.

    Reply
  10. Rustig

    (0) не на том форуме поднимаете проблемы 🙁 … сейчас 2019 год — а проблемы 2013 года еще не решены…. не в то ведомство пишите, значит…. одна статья — слишком маленькая никому не известная песочница…. вот если бы каждый лайк за статью уходил сразу письмом в отдел развития платформы 1С…. смогёте такое автоматизировать? 🙂

    Reply
  11. YPermitin

    (10) проще из разработки на платформе 1С уйти, чем эту проблему решить 🙂

    Reply
  12. Rustig

    (11) если решать одному, то «да», проще уйти… а если сообща?!….

    Reply
  13. YPermitin

    (12) сообща с кем и как?

    Reply
  14. Rustig

    (13) есть

    идея ;№1. создайте тему (ветку) на форуме разработчиков 1с — можете несколько тем — у вас вроде несколько тем актуальных…

    ссылку на тему оставьте здесь — с подписью «поддержите решение вопроса».

    я бы перешел и уже там поставил лайк…

    при этом описывая проблему на форуме разработчиков , можете оставить ссылку на статью…

    идея №2. Разработать внешнюю обработку для отправки писем-вопросов в техподдержку 1С.

    Создать пару полей в ней: ссылка на статью ИС + идентиф. собственные данные. Письмо генерируется шаблонно.

    Reply
  15. YPermitin

    (14) идеи хорошие. Надо подумать.

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

    Reply
  16. Rustig

    (15) по сути вы только что снизили приоритет своих вопросов…

    больше уверенности, коллеги 1с-ники!

    к примеру, сравнение объектов — элементов и свойств — было бы актуально для любых платформ — на обычных и управляемых форм…

    …мы сами не знаем куда нас приведут наши идеи… (я о черных лебедях)

    Reply
  17. YPermitin

    (16) мои слова — это результат опыта. Если у вас другой, то жто отлично 🙂

    Reply
  18. Rustig

    (17) я понял, но вы про опыт одного человека.

    я предлагаю объединять умы — вместе пробовать изменить ситуацию.

    Reply
  19. Rustig

    (15) в тему https://m.habr.com/ru/post/470561/

    можно расшатать их только совместными усилиями….

    Reply
  20. Rustig
  21. davdykin

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

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *