Программное добавление и изменение элементов управляемых форм. Программное добавление и изменение элементов управляемых форм Функциональность по умолчанию

И Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

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

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

  • Толстый клиент (обычный и управляемый режим запуска)
  • Тонкий клиент
  • Веб-клиент
В управляемом приложении используются формы, построенные на новой технологии. Они называются Управляемые формы . Для облегчения перехода прежние формы (т.н. Обычные формы) также поддерживаются, но их функциональность не развивается и они доступны только в режиме запуска толстого клиента.
Основные отличия управляемых форм для разработчика:
  • Декларативное, а не «по пикселям» описание структуры. Конкретное размещение элементов выполняется системой автоматически при отображении формы.
  • Вся функциональность формы описывается в виде реквизитов и команд . Реквизиты – это данные, с которыми работает форма, а команды – выполняемые действия.
  • Форма выполняется и на сервере и на клиенте.
  • В контексте клиента, недоступны практически все прикладные типы, и соответственно невозможно изменить данные в информационной базе.
  • Для каждого метода или переменной формы обязательно должна быть указана директива компиляции , определяющая, место выполнения (клиент или сервер) и доступ к контексту формы.
Перечислим директивы компиляции методов формы:
  • &НаКлиенте
  • &НаСервере
  • &НаСервереБезКонтекста
  • &НаКлиентеНаСервереБезКонтекста
Проиллюстрируем перечисленное. На скриншоте пример управляемой формы и ее модуля в режиме разработки. Найдите декларативное описание, реквизиты, директивы компиляции и т.д.

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

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

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Секция обработчиков событий Метод – наклиенте Метод – насервере Метод - наклиенте Секция служебных процедур и функций Вспомогательные функции управления вводом
Пример 2:
Служебные процедуры и функции Документы оплаты Ценности Обработчики событий
Пример 3:
Служебные процедуры на сервере Служебные процедуры на клиенте Служебные процедуры на сервере без контекста Обработчики событий шапки Обработчики событий команд
Пример 4:
Процедуры общего назначения Обработчики событий формы Процедуры подсистемы «контактная информация»
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 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:
// на сервере в контексте формы ОбработкаОбъект = РеквизитФормыВЗначение("Объект"); ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка); ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

  • Примитивные типы (строка, число, булево)
  • Структура
  • Соответствие
  • Массив
  • Ссылки на прикладные объекты (уникальный идентификатор и текстовое представление)
Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
&НаСервереБезКонтекста Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус) Ошибки = Новый Соответствие(); // [заказ][описание ошибки] Для Каждого Заказ Из Заказы Цикл НачатьТранзакцию(); Попытка ДокОб = Заказ.ПолучитьОбъект(); …. другие действия, возможно не только с заказом… Исключение ОтменитьТранзакцию(); Ошибки.Вставить(Заказ, ОписаниеОшибки()); КонецПопытки; КонецЦикла; Возврат Ошибки; КонецФункции // СерверИзменитьСтатусЗаказов()

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

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

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Дата=""/> // <Описание> // // //////////////////////////////////////////////////////////////////////////////// // ПЕРЕМЕННЫЕ МОДУЛЯ //////////////////////////////////////////////////////////////////////////////// // НА СЕРВЕРЕ //******* СОБЫТИЯ НА СЕРВЕРЕ ******* &НаСервере Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) //Вставить содержимое обработчика КонецПроцедуры //******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА ******* //******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА //////////////////////////////////////////////////////////////////////////////// // НА КЛИЕНТЕ //******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ ******* //******* КОМАНДЫ ******* //******* СОБЫТИЯ НА КЛИЕНТЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

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

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

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

Настройка панели разделов

Изменить состав панели разделов можно в Конфигураторе в режиме 1С:Предприятие .

Настройка начальной страницы

Состав форм, находящихся на начальной странице, можно изменить в Конфигураторе с детализацией по ролям, или индивидуально для одного или нескольких пользователей в режиме 1С:Предприятие .

Настройка командного интерфейса основного раздела

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

Настройка командных интерфейсов разделов

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

Настройка форм

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

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

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

В управляемой форме можно программно добавить, изменить и удалить:

  • реквизиты;
  • локальные команды;
  • элементы.

Все указанные операции возможны только на сервере.

Программное изменение формы имеет ограничения:

  • Удалить можно только программно добавленные реквизиты/команды/элементы. Нельзя программно удалить объекты, созданные в конфигураторе.
  • Нельзя назначить реквизит основным.

Изменение команд формы

Для управления составом команд у объекта УправляемаяФорма есть коллекция Команды

    Добавить(< ИмяКоманды >)

    Количество ()

    Найти(< ИмяКоманды >)

    Удалить(< Команда >)

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

В качестве примера работы с командами формы создадим новую команду ИсторияИзменений с заголовком «История изменений…», которая будет вызвать обработчик ОтобразитьИсторию () . Создание выполняется при открытии формы.

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Команда = Команды. Добавить(«ИсторияИзменений» );
Команда. Действие = ;
Команда. Заголовок = «История изменений…» ;
КонецПроцедуры
&НаКлиенте
Процедура Подключаемый_ОтобразитьИсторию(Команда )
// действия команды
КонецПроцедуры

Обработчик команды должен располагаться в форме и иметь директиву компиляции &НаКлиенте .

Изменение реквизитов формы

Чтение состава реквизитов формы выполняется функцией ПолучитьРеквизиты (< Путь >) , возвращающей массив типа РеквизитФормы . Параметр функции указывает путь к родительскому реквизиту (в виде строки). Если параметр опущен или указана пустая строка, возвращаются реквизиты верхнего уровня.

Изменение реквизитов выполняется методом ИзменитьРеквизиты (<ДобавляемыеРеквизиты >, <УдаляемыеРеквизиты >) объекта УправляемаяФорма . В параметры ДобавляемыеРеквизиты и УдаляемыеРеквизиты передаются массивы с элементами типа РеквизитФормы .

Внимание!

Процесс изменения состава реквизитов является достаточно ресурсоемким. Фактически выполняется пересоздание формы. В связи с этим работа с реквизитами формы выполняется в пакетном режиме.

Создадим новый реквизит формы с именем Покупатель:


ДобавляемыеРеквизиты = Новый Массив;
ДобавляемыеРеквизиты. Добавить(Новый РеквизитФормы («Покупатель», Новый ОписаниеТипов («СправочникСсылка.Контрагенты»), «Клиент»));

// Изменения состава реквизитов
);

Изменение элементов формы

Для управления составом элементов у объекта УправляемаяФорма есть коллекция Элементы . У коллекции есть несколько методов:

    Вставить(< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

    Добавить(< Имя>, < ТипЭлемента>, < Родитель >)

    Количество ()

    Найти(< Имя >)

    Переместить(< Элемент>, < Родитель>, < МестоРасположения >)

    Удалить(< Элемент >)

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

  • ГруппаФормы;
  • ТаблицаФормы;
  • ПолеФормы;
  • КнопкаФормы.

Элементам формы можно программно назначить обработчики событий. Для этих целей предназначен метод УстановитьДействие(< ИмяСобытия>, < Действие >) .

Рассмотрим несколько наиболее распространенных на практике примеров работы с командами, реквизитами и элементами формы.

Добавление команды и связанной с ней кнопки:

// Создание команды
Команда = Команды. Добавить(«ИсторияИзменений» );
Команда. Действие = «Подключаемый_ОтобразитьИсторию» ; // В форме должна быть процедура с указанным наименованием
Команда. Заголовок = «История изменений…» ;
// Создание кнопки и связь ее с командой
Элемент = Элементы. Добавить(«ИсторияИзменений» , Тип(«КнопкаФормы» ));
Элемент.ИмяКоманды = «ИсторияИзменений» ;

Добавление реквизита и связанного с ним поля ввода:

// Описание добавляемых реквизитов
ДобавляемыеРеквизиты = Новый Массив;
ДобавляемыеРеквизиты. Добавить (Новый РеквизитФормы («Покупатель» , Новый ОписаниеТипов («СправочникСсылка.Контрагенты» ), «Клиент» ));
// Изменение состава реквизитов
ИзменитьРеквизиты(ДобавляемыеРеквизиты );
// Создание поля ввода и связь с реквизитом
Элемент = Элементы. Добавить(«Покупатель» , Тип(«ПолеФормы» ));
Элемент. Вид = ВидПоляФормы. ПолеВвода;
Элемент. ПутьКДанным = «Покупатель» ;

Назначение элементу формы обработчика события:

ЭлементПокупатель. УстановитьДействие («ПриИзменении» , «Подключаемый_ПокупательПриИзменении» );

&НаКлиенте
Процедура Подключаемый_ПокупательПриИзменении (Элемент )
// Действия события
КонецПроцедуры

Внимание!

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

Внимание!

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

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

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

  • Самостоятельное формирование структуры формы и размещение полей платформой. Если раньше разработчики описывали положение поля, указывая пиксели, то теперь есть возможность лишь указать вид группировки;
  • Форма состоит из реквизитов, представляющих данные формы, и команд – выполняемых процедур и функций;
  • Код формы выполняется на стороне и сервера, и клиента. Ведь сама по себе форма – это объект конфигурации, создаваемый на сервере и отображаемый на клиенте. Значит, объединяет в себе клиентскую и серверную часть;
  • На клиентской стороне стали недоступны многие типы данных и теперь отсутствует возможность изменить данные в информационной базе;
  • Для каждой процедуры или функции должна быть указана специальная настройка – директива компиляции. Она отвечает за место выполнения кода и может принимать следующие значения:
    • Наклиенте;
    • НаСервере;
    • НаСервереБезКонтекста;
    • НаКлиентеНаСервере;
    • НаКлиентеНаСервереБезКонтекста.

Последний пункт особо остро стоит в режиме управляемых форм. Если разработчик плохо разбирается в директивах или взаимодействии клиента и сервера, то ему будет крайне сложно создать управляемую форму. Все новые принципы построения управляемых форм в 1С:Предприятие 8.3 объединены общим понятием трехзвенной архитектуры. В нее входят клиентские компьютеры, сервер 1С и СУБД, где хранятся данные.

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

  1. Элементы интерфейса формы. Слева вверху расположено окно, где перечислены все поля, отраженные на выбранной форме, обеспечивающие взаимодействие программы с пользователем;
  2. Реквизиты формы. Справа вверху расположены все данные, с которыми работает форма. Именно в них хранится информация на клиентской стороне;
  3. Отображение управляемой формы. Снизу мы видим предварительный внешний вид на основе элементов интерфейса;
  4. Модуль формы. Раздел, содержащий процедуры и функции, используемые данной формой. Здесь можно найти код алгоритмов взаимодействия программы и с пользователем, и с базой данных.

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

Принципы разработки управляемых форм

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

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

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

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

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

  1. Простота сопровождения конфигурации и повышенная читаемость кода. Отсюда можно сделать вывод, что алгоритм, написанный одним разработчиком, всегда сможет поправить другой сотрудник, не тратя много времени;
  2. Разделение кода, выполняемого на клиенте и сервере. Учитывая, насколько отличается функционал, доступный на каждой из этих сторон, разделить их было бы правильным шагом;
  3. Более глубокое понимание разработчиками логики платформы, взаимодействия клиента и сервера и алгоритмов, которые они пишут. В версиях 8.0 и ранее очень часто можно было встретить формы документов или справочников, разработанные без понимания клиент-серверной части;
  4. Повышение быстродействия конфигураций и снижение нагрузки на клиентские компьютеры;
  5. Снижение затрат на закупку компьютеров для рабочих мест ввиду отсутствия необходимости приобретения мощных ПК.

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

1С создаются системой автоматически при использовании прикладного решения. Являются основой представления (отображения) информации в системе "1С:Предприятие".

Структура формы 1С

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

Отображаемая часть формы (видимая пользователю) описывается как дерево, включающее элементы формы (см. рис. ниже, поле "Элементы формы"):

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

"Элементы формы 1С"

[свернуть]

Группа элементов формы может представляться как

  1. панель с рамкой,
  2. панель со страницами (закладками),
  3. собственно страница,
  4. командная панель.

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

  • реквизитов (данных, с которыми работает форма);
  • команд (выполняемых действий).

Настройка внешнего вида управляемой формы

Настройка внешнего вида управляемой формы пользователем

Настройка внешнего вида управляемой формы может осуществляться на пользовательском уровне. Для данной возможности в действиях формы существует команда "Ещё" - "Изменить форму" (управление только теми элементами формы, которые определены на этапе разработки или по стандартным правилам автогенерации формы).

"Ещё" - "Изменить форму"

Команда "Ещё" - "Изменить форму":

После нажатия "Изменить форму" показывается окно настройки формы 1С:

[свернуть]

Кроме того, в пользовательском режиме возможно:


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

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

Настройка внешнего вида управляемой формы разработчиком

Разработчик может влиять на расположение элементов различными установками. Он может определять порядок элементов, указывать их ширину и высоту, а также использовать:

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

Рисунок (изменение формы 1С разработчиком)

[свернуть]

При разработке формы 1С необходимо:

  1. в редакторе формы включить в форму необходимые реквизиты и команды;
  2. создать отображающие их элементы формы, определить порядок элементов, указать ширину и высоту (при необходимости);
  3. скомпоновать элементы в группы (если необходимо).
  1. Использовать ролевую настройку видимости в элементах форм (просмотр и редактирование реквизитов по , пользовательскую видимость полей формы по ролям, использование команд по ролям) в случае большого количества ролей в конфигурации (от нескольких десятков). Вместо этого следует придерживаться следующих подходов:
    • при сильных различиях внешнего вида и функциональности формы в зависимости от наличия тех или иных ролей у пользователя – разрабатывать отдельные формы , специализированные под конкретный набор прав пользователя;
    • при незначительных отличиях – выполнять проверку прав в коде . При этом следует иметь в виду, что программное управление видимостью может снизить скорость открытия формы, что нужно учитывать при выборе между предлагаемыми подходами.
  2. Использовать ролевую настройку видимости в командном интерфейсе конфигурации, командном интерфейсе основного раздела, а также рабочей области начальной страницы. Вместо этого следует использовать настройку прав на разделы командного интерфейса, и объекты, включенные в командный интерфейс или в рабочую область. Это позволяет повысить предсказуемость поведения управляемого интерфейса для пользователя, а также упростить расследование ошибок.

Более подробную информацию по работе с формами в курсе "Работа с формами в "1С:Предприятии 8.3", http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=161.



 

Возможно, будет полезно почитать: