Главная » Содержание » Под капотом управляемых форм. СтавАналит. Контактная информация Использовать всегда управляемые формы 1с

Под капотом управляемых форм. СтавАналит. Контактная информация Использовать всегда управляемые формы 1с

В этой статье мы познакомимся с основными аспектам работы с управляемой формой в 1С 8.3. Что такое форма и для чего она нужна? Форма это основной объект, посредством которого осуществляется взаимодействие пользователя с программой. То есть с помощью формы пользователь осуществляет ввод информации в программу, а так же на форму выводиться нужная для пользователя информация.

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

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

Подробно вопросы работы с управляемыми формами в частности и с управляемым приложением в целом рассмотрены в книге «Основы разработки в 1С: Такси. Разработка управляемого приложения за 12 шагов» . Эта книга станет настоящим подспорьем для тех, кто только начал знакомится с разработкой управляемого приложения.

Книга «Основы разработки в 1С: Такси» отлично подойдёт тем, кто уже начал программировать и испытывает определенные сложности с этой темой и тем, кто уже давно программирует, но ни разу еще не работал с управляемыми формами 1С

Без сложных технических терминов;
Более 600 страниц практического материала;
Каждый пример сопровождается рисунком (скриншот);

Промо-код на скидку в 15% — 48PVXHeYu

Иногда кажется, что изучить язык программирование в 1С сложно и трудно. В действительности программировать в 1С — легко. Помогут Вам легко и быстро освоить программирование в 1С мои книги: и «Основы разработки в 1С: Такси»

Изучите программирование в 1С с помощью моей книги «Программировать в 1С за 11 шагов»

Без сложных технических терминов.
Более 700 страниц практического материала.
Каждое задание сопровождается рисунком (скриншот).
Сборник задач для домашней проработки.
Книга написана понятным и простым языком — для новичка.
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!

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

можно оплатить вручную:

Яндекс.Деньги — 410012882996301
Web Money — R955262494655

Вступайте в мои группы.

Публикую вторую главу моей книги «Основы разработки в 1С: Такси»

Глава 2.Обычное и управляемое приложение 1С

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

Что вообще такое «интерфейс»? По сути, это общая граница между двумя взаимодействующими системами (очень часто одной системой является человек). Возьмем, например, автомобиль. Есть ли у него интерфейс? Да, конечно. Но что же является общей границей между автомобилем и человеком? Во-первых, это рабочее место, т.е. непосредственно водительское сиденье и органы управление (руль, педаль акселератора, педаль тормоза и т.д.). Во-вторых, это принципы взаимодействия человека с автомобилем, которые являются каким-то набором правил. Например, для того, чтобы ускорить автомобиль, нужно нажать педаль газа, замедлить – педаль тормоза, для поворота направо нужно выкрутить руль вправо и т.д. Благодаря двум этим сущностям человек может управлять автомобилем. Уберите что-то одно, и управление автомобилем не станет возможным.

В мире программного обеспечения все точно так же. Одна система это человек – оператор, пользователь. А вторая система это некоторое приложение, созданное для автоматизации определенного вида человеческой деятельности (мы рассматриваем прикладное программирование).

Например, нам нужно самостоятельно вести складской учет: осуществлять приход товара на склад, списание этого товара и следить за остатками. Что же будет являться общей границей между приложением, без разницы, как и где написанным, и пользователем? Во-первых, это органы ввода информации — иначе как Вы передадите в программу, что на склад пришло 5 штук какой-то продукции. В нашем случае это компьютерная клавиатура и компьютерная мышка. Во-вторых, это система взаимодействия между компьютером и человеком. Например, это может быть интерфейс командной строки: Вы будете с помощью клавиатуры вводить различные текстовые строки (команды) и с их помощью выполнять нужные действия (фиксировать приход товара, расход товара и пр.). Такой интерфейс выглядит примерно так: см. рис. 1.2.1.

Рис. 1.2.1 Пример командной строки

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

Данный вид интерфейса давно является архаичным, и на его смену пришел графический интерфейс пользователя (анг. graphical user interface GUI). В этом интерфейсе взаимодействие между пользователем и приложением происходит посредством различных графических элементов, нарисованных на дисплее (кнопки, иконки, переключатели и т.п). В графическом интерфейсе оператор имеет произвольный доступ посредством органов управления к любым графическим элементами. В нашем случае, когда автоматизируем складской учет, взаимодействие может выглядеть так: оператор нажимает кнопку «Приход», открывается форма подбора товара, где оператор выбирает нужный товар из списка и вводит его количество. Если нужно осуществить расход, то оператор нажимает кнопку «Расход», так же открывается форма подбора, где оператор так же выбирает нужный товар и вводит его количество. Когда нужно сверить остатки, оператор нажимает на кнопку «Остатки», и программа выводит ему остатки товара на складе. Тем самым с помощью данного графического интерфейса Вы можете вполне успешно вести учет товаров на складе.

Закончим с теоретической частью и перейдем непосредственно к теме данной главы. А именно к видам интерфейсов приложения программы 1С, которые все являются графическими интерфейсами пользователя. У программы «1С: Предприятие 8» существуют два глобальных вида графических интерфейсов приложений. Это режим обычного приложения и режим приложения под управляемыми формами (или управляемое приложение).

Платформы редакции 8.0 и 8.1. работали только под обычным режимом, более высокие версии платформы (8.2, 8.3 и т.д.) могут работать и в режиме обычного приложения, и в режиме управляемого приложения.

Режим обычного приложения

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

В режиме обычного приложения используется интерфейс и формы, которые применялись в платформах 8.0 и 8.1. Раньше этот режим никак не назывался, сейчас же он называется «режим обычного приложения», а формы, которые используются в этом режиме, называются «обычные формы».

Посмотрим вкратце, как выглядит этот режим. Многим он уже будет знаком, но некоторые, особенно те, кто не застал работу под платформами 8.0 и 8.1, его увидят в первый раз.

После загрузки программы пользователь видит интерфейс с меню в его верхней части (см. рис. 1.2.2).

Рис 1.2.2 Вид интерфейса обычного приложения

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

Рис.1.2.3. Форма списка документов

Из формы списка пользователь может открыть форму документа или справочника (см. рис. 1.2.4).

Рис. 1.2.4. Форма документа

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

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

Рис 1.2.5. Конструирование обычных форм

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

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

Режим управляемого приложения

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

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

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

Рис. 1.2.6. Управляемый командный интерфейс

При разработке управляемого приложения программисту придется идти немного другим путем. Прежде чем разрабатывать бизнес-логику, нам нужно определить подсистемы, в которые будут входить наши объекты (в обычном приложении они тоже есть, но носят больше декларативный характер). Например, документ «Приход товаров» будет входить в подсистему «Снабжение», а документ «Расход товаров» будет входить в подсистему «Продажи». В то же время некоторые объекты могут находиться в нескольких подсистемах одновременно: справочник «Товары» будет входить и в подсистему «Продажи», и в подсистему «Снабжение», и в подсистему «Маркетинг». В этом случае разработчику нет необходимости создавать объект «Интерфейс», система сама автоматически построит нужный вид интерфейса исходя из настроек прав пользователя и функциональных опций.

Если у какого-то пользователя будет роль, в которой нет прав на просмотр подсистемы, например «Снабжение», то при запуске приложения 1С он просто не увидит этот пункт меню. Так же он не увидит в списке меню документ, на который у него нет права хотя бы на просмотр.

На рисунке 1.2.6 Вы видели интерфейс пользователя с полными правами, а, например, интерфейс продавца будет выглядеть так:

Рис. 1.2.7. Интерфейс пользователя с ограниченными правами

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

Рис. 1.2.8. Интерфейс пользователя с урезанными функциями текущего раздела

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

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

Теперь разберем, что же такое управляемые формы.

Изучите программирование в 1С с помощью моей книги «Программировать в 1С за 11 шагов»

Без сложных технических терминов.
Более 700 страниц практического материала.
Каждое задание сопровождается рисунком (скриншот).
Сборник задач для домашней проработки.
Книга написана понятным и простым языком — для новичка.
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!

можно оплатить вручную:

Яндекс.Деньги — 410012882996301
Web Money — R955262494655

Вступайте в мои группы.

Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

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

В 2008 году стала доступна новая версия платформы 1С: Предприятие 8.2 (далее Управляемое приложение), которая полностью меняет весь слой работы с интерфейсом. Сюда относится и командный интерфейс, и формы, и оконная система. При этом не только меняется модель разработки пользовательского интерфейса в конфигурации, но и предлагается новая архитектура разделения функциональности между клиентским приложением и сервером.

Управляемое приложение поддерживает следующие типы клиентов:

Толстый клиент (обычный и управляемый режим запуска)
Тонкий клиент
Веб-клиент

В управляемом приложении используются формы, построенные на новой технологии. Они называются Управляемые формы. Для облегчения перехода прежние формы (т.н. Обычные формы) также поддерживаются, но их функциональность не развивается и они доступны только в режиме запуска толстого клиента.

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

Декларативное, а не «по пикселям» описание структуры. Конкретное размещение элементов выполняется системой автоматически при отображении формы.
Вся функциональность формы описывается в виде реквизитов и команд. Реквизиты – это данные, с которыми работает форма, а команды – выполняемые действия.
Форма выполняется и на сервере и на клиенте.
В контексте клиента, недоступны практически все прикладные типы, и соответственно невозможно изменить данные в информационной базе.
Для каждого метода или переменной формы обязательно должна быть указана директива компиляции, определяющая, место выполнения (клиент или сервер) и доступ к контексту формы.

Перечислим директивы компиляции методов формы:

&НаКлиенте

&НаСервере

&НаСервереБезКонтекста

&НаКлиентеНаСервереБезКонтекста

Проиллюстрируем перечисленное. На скриншоте пример управляемой формы и ее модуля в режиме разработки. Найдите декларативное описание, реквизиты, директивы компиляции и т.д.

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

Обозначим проблему

Прошло уже несколько лет как новая версия платформы 1С активно используется и выпущено множество решений (конфигураций) как фирмой 1С, так и ее многочисленными партнерами.

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.

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

Секция обработчиков событий

Метод – наклиенте

Метод – насервере

Метод - наклиенте

Секция служебных процедур и функций

Вспомогательные функции управления вводом

Служебные процедуры и функции

Документы оплаты

Ценности

Обработчики событий

Служебные процедуры на сервере

Служебные процедуры на клиенте

Служебные процедуры на сервере без контекста

Обработчики событий шапки

Обработчики событий команд

Процедуры общего назначения

Обработчики событий формы

Процедуры подсистемы «контактная информация»

По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

Неинформативные слова «Общие, Служебные, Вспомогательные».
Робкие попытки разделить клиентские и серверные методы.
Часто методы группируются по интерфейсным элементам «Работа с табличной частью Товары, Контактной информацией».
Произвольное расположение методов и групп кода. Например, Обработчики событий могут быть в одной форме вверху, в другой внизу, в третьей вообще не выделены и т.д.
И не будем забывать, что это все в рамках одной конфигурации.
Да бывают конфигурации, в которых слова «Общие, Служебные, Вспомогательные» всегда находятся на одних и тех же местах но…

Зачем нужна структура кода?

Упрощение сопровождения.
Упрощение обучения.
Фиксация общих/важных/удачных принципов.
…ваш вариант

Почему существующий стандарт разработки от фирмы 1С не помогает?

Минимизируйте число серверных вызовов.
Максимум вычислений на сервере.
Неконтекстные вызовы сервера быстрее контекстных.
Программируйте с учетом клиент-серверного взаимодействия.
и т.п.

Это лозунги, абсолютно верные, но как их реализовать? Как минимизировать число вызовов, что значит программировать в клиент-серверном режиме?

Шаблоны проектирования или мудрость поколений

Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.

Remote Facade (далее Интерфейс удаленного доступа)
Data Transfer Object (далее Объект переноса данных)

Слово Мартину Фаулеру, его описание данных принципов:

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

Примеры шаблонов в платформе 1С

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

Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.

ПараметрыОткрытия = Новый Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3);

Форма = ОткрытьФорму(ИмяФормы, ПараметрыОткрытия);

Сравните с принятым в v8.1 стилем.

Форма = ПолучитьФорму(ИмяФормы);

Форма.Параметр1 = Значение1;

Форма.Параметр2 = Значение2;

Форма.Открыть();

В контексте управляемой формы множество «Объектов переноса данных». Можно выделить системные и определяемые разработчиком.

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

ДанныеФормыСтруктура

ДанныеФормыКоллекция

ДанныеФормыСтруктураСКоллекцией

ДанныеФормыДерево

Преобразование системных объектов переноса данных в прикладные типы и обратно выполняется методами:

ЗначениеВДанныеФормы()

ДанныеФормыВЗначение()

КопироватьДанныеФормы()

ЗначениеВРеквизитФормы()

РеквизитФормыВЗначение()

Часто явное преобразование используется при адаптации существующего решения. Методы могут ожидать (использовать особенности) входные параметры, например ТаблицаЗначений, а не ДанныеФормыКоллекция, или метод был определен в контексте прикладного объекта и стал недоступен для прямого вызова из формы.

Пример 1С v8.1:

// на клиенте в контексте формы

ЗаполнитьКэшПользователей(ПодразделениеСсылка)

Пример 1С v8.2:

// на сервере в контексте формы

ОбработкаОбъект = РеквизитФормыВЗначение("Объект");

ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка);

ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

Примитивные типы (строка, число, булево)

Структура

Соответствие

Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.

&НаСервереБезКонтекста

Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус)

Ошибки = Новый Соответствие(); // [заказ][описание ошибки]

Для Каждого Заказ Из Заказы Цикл

НачатьТранзакцию();

Попытка

ДокОб = Заказ.ПолучитьОбъект();

…. другие действия, возможно не только с заказом…

Исключение

ОтменитьТранзакцию();

Ошибки.Вставить(Заказ, ОписаниеОшибки());

КонецПопытки;

КонецЦикла;

Возврат Ошибки;

КонецФункции // СерверИзменитьСтатусЗаказов()

Структурируем код

Главные цели, которые должен отражать модуль управляемой формы и подходы к решению.

Четкое разделение клиентского и серверного кода. Не будем забывать, в момент выполнения это два взаимодействующих процесса, в каждом из которых существенно отличается доступный функционал.
Четкое выделение интерфейса удаленного доступа, какие методы сервера можно вызывать с клиента, а какие нельзя? Названия методов удаленного интерфейса начинаются с префикса «Сервер». Это позволяет, читая код сразу видеть переход управления на сервер, и упрощает использование контекстной подсказки. Отметим, что официальная рекомендация (ИТС) предлагает именовать методы с постфиксами, например, так ИзменитьСтатусЗаказовНаСервере(). Однако повторим не все серверные методы можно вызывать с клиента, и поэтому более важна логическая доступность, а не место компиляции. Поэтому префиксом «Сервер» отмечаем только методы доступные для клиента, метод-пример назовем СерверИзменитьСтатусЗаказов().
Удобочитаемость. Дело вкуса, принимаем порядок, когда модуль начинается с процедур создания формы на сервере и методов удаленного доступа.
Сопровождаемость. Должно быть однозначно определено место для добавления нового кода. Важный момент, автоматически создаваемые конфигуратором заготовки методов добавляются в конец модуля. Т.к чаще всего автоматически создаются обработчики событий элементов формы, то соответствующий блок расположен последним, чтобы не перетаскивать каждый обработчик в другое место модуля.

Ниже приведена базовая структура модуля, реализующая перечисленные цели.

Графический вариант – наглядно показывает основной поток выполнения.
Текстовый вариант - это пример оформления шаблона для быстрой вставки структуры в новый модуль формы.

// <Описание>

////////////////////////////////////////////////////////////////////////////////

// ПЕРЕМЕННЫЕ МОДУЛЯ

////////////////////////////////////////////////////////////////////////////////

// НА СЕРВЕРЕ

//******* СОБЫТИЯ НА СЕРВЕРЕ *******

&НаСервере

Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

//Вставить содержимое обработчика

КонецПроцедуры

//******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА *******

//******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ *******

////////////////////////////////////////////////////////////////////////////////

// ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА

////////////////////////////////////////////////////////////////////////////////

// НА КЛИЕНТЕ

//******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ *******

//******* КОМАНДЫ *******

//******* СОБЫТИЯ НА КЛИЕНТЕ *******

////////////////////////////////////////////////////////////////////////////////

// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

Связанные вопросы

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

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

В прошлом уроке мы с Вами рассмотрели для обычного (толстого) клиента. В версии платформы 1С 8.2 . В них используются новые экранные формы 1С 8.2. Их называют управляемые формы 1С 8.2.

Управляемые формы 1С 8.2 – это будущее 1С. Они отличаются от обычных форм 1С 8.2 тем, что генерируются системой автоматически на основе специальных настроек («обычные» формы просто рисуются программистом по своему желанию).

Различия в разработке управляемых форм 1С 8.2 от обычных – значительны. Поэтому мы собрались сегодня отдельно обсудить создание и изменение управляемых форм 1С 8.2.

Управляемые формы 1С 8.2

Если Вы занимались разработкой конфигураций 1С ранее – при открытии редактора управляемой формы 1С 8.2 Вас сразу поставит в тупик то, что мышкой невозможно повлиять на форму 1С 8.2 вообще.

Нельзя изменить форму 1С 8.2, нельзя передвинуть элемент, нельзя даже посмотреть свойства поля как раньше – кликнув два раза мышкой поле на форме 1С 8.2.

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

Настройки состоят из списка элементов формы 1С 8.2, расположенных в редакторе в верхнем левом углу. В элементы формы 1С 8.2 входят:

Реквизиты
Команды (новое понятие 1С 8.2, могут выглядеть как кнопки или пункты меню)
Группы (для объединения реквизитов и команд).

Соответственно настройки этих элементов находятся не в свойствах полей, а в свойствах этих элементов настройки (меню по правой кнопке мыши, пункт Свойства).

Как работают управляемые формы 1С 8.2

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

В первую очередь отличается расположение привычных элементов на форме 1С 8.2. Командная панель всегда находится вверху.

Левая часть командной панели настраиваемая. В ней обычно находятся такие типовые кнопки как Записать и Провести.

Правая часть командной панели – новое стандартное меню формы 1С Все действия. Это меню позволяет управлять формой 1С 8.2 по своему желанию, наподобии, как в отчете СКД настройки позволяют значительно изменить вид отчета.

Произвольные пункты меню 1С Все действия

В зависимости от принадлежности данной формы 1С 8.1 к тому или иному , меню наполнено пунктами, позволяющими управлять этим объектом. Например, если это форма списка справочника, то там будут такие команды как Создать или Редактировать.

Пункт Настроить список меню 1С Все действия

Если на форме 1С 8.2 есть список, то в меню есть команда Настроить список и Вывести список.
Если команда Вывести список Вам уже знакома – она позволяет любой список в 1С сохранить в Excel/вывести на печать, то вторая команда – новая.

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

Функционал кнопки Найти конечно же не сравним с отборами, но они никуда и не делись!
Они теперь находятся в пункте меню Настроить список. Отбор теперь можно делать по любому полю, а кроме него можно сделать сортировку и условное оформление также, как это можно делать в отчетах СКД.

Пункт Изменить форму меню 1С Все действия

Пункт Изменить форму позволяет подобным образом изменить не только список на форме 1С 8.2, но и саму форму 1С 8.2.

Пользователь самостоятельно может включить или отключить видимость полей на форме 1С 8.2, ширину и высоту, активизация поля по умолчанию при открытии и т.п.

Использование управляемых форм 1С 8.2 и обычных форм 1С

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

Для этого необходимо и войти в свойства конфигурации (верхний элемент в окне конфигурации).

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

Создание управляемых форм 8.2

Добавление новой формы 1С 8.2 производится также, как и раньше – с помощью кнопки Ins на клавиатуре или кнопки Добавить. Чтобы войти в существующую – нажмите на нее два раза мышкой.

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

Конструктор предложит Вам выбрать вид формы – форма элемента, списка. Здесь же можно добавить или убрать командные панели на форме. Чаще всего эти настройки оставляются как есть, по умолчанию.

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

Редактор формы состоит из трех разделов.

В левом верхнем углу находится список элементов формы. Он состоит из полей, команд и групп, которые позволяют объединять элементы. Список команд отдельно можно посмотреть там же на закладке Командный интерфейс.
В правом верхнем углу находится список доступных реквизитов формы и реквизитов объекта (раскройте крестик у реквизита Объект).
Внизу находится предпросмотр полученной формы.

Доступные реквизиты Вы можете перетащить влево и он станет элементом формы (полем на форме).

Если Вам нужно добавить кнопку или пункт меню – справа на закладке Команды Вам нужно создать новую Команду. Это оболочка для функции в модуле формы. Кроме указания собственно какая функция будет вызываться, Вы можете назначить представление – например, картинку, а также зависимость видимости от функциональной опции.

Команды также перетаскиваются влево. Если родителем стала командная панель, то это будет кнопка командной панели – иначе просто кнопкой.

В список элементов формы (полей) можно не только перетащить реквизит объекта/формы, но и просто добавить (кнопка Добавить или Ins). В частности можно новый объект формы – Группу.

Группа может быть командной панелью (курсор должен стоять на строке Форма). Тогда Вы перетаскиваете в нее команды и они становятся кнопками.

Группа может быть «обычной». Тогда это способ группировки полей как вертикально, так и горизонтально. Наименование группы можно убрать в свойствах.

Группа может быть панелью (страницы). Верхняя добавленная группа является панелью, а вложенные группы этого типа являются страницами. На страницы перетаскиваются уже поля.

Ненужные элементы формы удаляются путем удаления элементов формы в списке.
Позиция поля на форме определяется порядком в списке элементов (вертикальная) или с помощью групп (горизонтальная). Ширина и высота задаются в свойствах элемента формы.

Свойства элемента формы значительно расширились и содержат множество полезных вещей – как управления внешним видом (кнопки выбора и очистки), так и проверки значений по умолчанию.

Свойства самой формы, в том числе и ее размеры задаются у корневого элемента формы с аналогичным названием Форма.

Обработчики событий (ответ на действия пользователя) теперь поделились на два вида. Старые – как и раньше указываются в свойствах формы и полей (например, ПриИзменении и ПриОткрытии формы). Новые – стали командами и используются для пунктов меню и кнопок.

Допустим, есть внешняя обработка, написанная для версии 8.1. Можно ли запустить ее в версии 8.2 так, чтобы работать с ее старой, неуправляемой формой? Обработка нужна всего один раз, для переноса данных, и создавать для нее управляемую форму ради одного раза не хочется...

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

Обычные (неуправляемые) формы могут работать только в толстом клиенте. Тонкий и веб-клиенты поддерживают работу только с управляемыми формами.

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

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

При этом нужно помнить, что запуск клиентов в управляемом режиме возможен только в том случае, если у конфигурации отключена совместимость в версией 8.1 (свойство РежимСовместимости ).

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

Возможность использования обычных форм в управляемом режиме регулируется специальным свойством конфигурации - ИспользоватьОбычныеФормыВУправляемомПриложении . Это свойство нужно установить.

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

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

В других случаях (если у объекта нет ни одной основной формы или у объекта есть управляемая основная форма) платформой будет по умолчанию генерироваться или открываться (если она есть) управляемая форма.

Напечатать