1С 8.3 : Последовательность событий при открытии формы нового элемента
Последовательность событий, которые происходят при открытии формы нового элемента, можно представить следующей схемой:
Прежде всего, при заполнении нового объекта данными, можно попробовать обойтись вообще без написания какого-либо кода. Для этого у реквизитов объектов конфигурации есть свойства ЗначениеЗаполнения и ЗаполнятьИзДанныхЗаполнения.
Эти свойства позволяют визуально (в конфигураторе) задать правила, по которым реквизит будет заполняться данными при создании нового объекта.
Если этих возможностей недостаточно, то тогда нужно использовать возможности встроенного языка.
Действия с данными объекта нужно выполнять в модуле объекта, в обработчике события ОбработкаЗаполнения. Этот событие возникает только при создании новых объектов, при открытии форм существующих объектов это событие не вызывается. Поэтому в нем не нужно узнавать, новый это объект, или нет. Нужно только описать алгоритм заполнения объекта данными. При этом следует учитывать, что это событие будет вызываться в нескольких случаях:
При этом параметр Основание, передаваемый в этот обработчик, может иметь различные значения в зависимости от того, каким образом создается новый элемент.
Например, он может иметь тип ссылки, если новый объект вводится на основании.
Или он может иметь тип Структура, если новый объект создается интерактивной командой из списка, в котором установлен отбор. В этом случае структура будет содержать значения элементов отбора этого списка.
Также этот параметр может иметь тип Неопределено, если новый элемент создается интерактивной командой из панели действий. То есть в своем алгоритме начального заполнения полезно анализировать этот параметр.
Что касается внешнего вида формы нового объекта, то им нужно управлять в обработчике события формы ПриСозданииНаСервере.
Это событие возникает и для новых, и для существующих объектов. Поэтому в нем нужно убедиться в том, что открывается форма именно нового объекта. Убедиться в этом можно проанализировав параметр формы Ключ.
Если объект новый, в этом параметре будет пустая ссылка. Если это существующий объект – в этом параметре будет ссылка на этот объект:
Если требуется выполнять какие-то действия в обработчике события формы ПриОткрытии, то в нем ситуация аналогичная, нужно анализировать параметр формы Ключ.
Для тех кто не хочет читать все что выше, код проверки на ЭтоНовый в Управляемом приложении:
Методика обновления формы объекта данных при изменении объекта
Актуально для платформы 1С 8.2-8.3.17 (выше не проверял)
Под формой объекта данных в статье подразумевается форма ссылочного объекта (элемента справочника, документа и т.д.) или форма записи независимого регистра сведений.
Пусть в объекте есть строковый реквизит Наименование, длину значения которого мы хотим отображать на форме этого объекта. Добавляем в форму реквизит ДлинаСтроки типа Число и отображаем его в одноименное нередактируемое поле.
Также пусть в объекте есть реквизит типа ХранилищеЗначения, тип которого мы также хотим отображать в форме. Добавляем в форму реквизит ТипЗначенияВХранилище типа Строка и отображаем его в одноименное нередактируемое поле.
В каких же ситуациях нам потребуется обновлять эти косвенно связанные с объектом реквизиты?
Разумеется это нужно вызывать в событии ПриИзменении поля Наименование. А вот дальше многие ограничиваются только вызовом в ПриСозданииНаСервере[упр] и ПриОткрытии[обыч]. Тем самым они не учитывют
Примеры использования команды «Перечитать»
Случай 1
Объект данных, отображаемый в форме, мог быть изменен в БД с момента его загрузки в форму. Типичные способы таких изменений
Тогда при попытке начать изменение любого поля формы, напрямую связанного с данными (флаг «Изменяет данные»), пользователь увидит предупреждение «Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!»
Это результат срабатывания так называемой оптимистической объектной блокировки. Она гарантирует, что если пользователь изменяет объект, то его изменения не «затрут» изменения, сделанные другими сеансами или другими программными объектами этого же сеанса. И тогда, чтобы получить возможность редактировать объект, нужно будет его перечитать либо переоткрыть форму.
Случай 2
Пользователь изменил данные в форме и решил отменить сделанные изменения, но продолжить редактировать объект от его текущего состояния в БД.
В каких событиях обновлять форму?
Чтобы учесть все эти тонкости, нужно всю логику обновления косвенно связанных с объектом элементов формы поместить в процедуру ПриСозданииПриЧтенииНаСервере и вызывать ее из следующих обработчиков событий формы:
Управляемая форма
Обычная форма
Управляемая форма
В управляемой форме при открытии существующего объекта выполняются два обработчика: сначала ПриЧтенииНаСервере и затем ПриСозданииНаСервере. Поэтому процедура ПриСозданииПриЧтенииНаСервере будет вызываться 2 раза подряд и нужно не задублировать выполнение логики обновления формы. Элементы формы могут зависеть как от данных объекта, доступных через реквизит формы, так и от недоступных через него (реквизиты типа ХранилищеЗначений), которые доступны только одном из них (ПриЧтенииНаСервере). Поэтому в процедуре ПриСозданииПриЧтенииНаСервере надо предусмотреть оба вызова таким образом, чтобы при создании формы существующего объекта при ее вызове из ПриЧтенииНаСервере выполнилась только логика работы с хранилищами значений, а при последующем вызове из ПриСозданииНаСервере выполнилась только логика, зависящая от остальных данных объекта. При этом ее вызов из уже открытой формы (из ПриЧтенииНаСервере и ПослеЗаписиНаСервере) должен выполнять все действия. Для этого создадим в общем модуле функцию ЭтоВызовПослеОткрытияФормы, где будем проверять наличие параметра ТолькоПросмотр у формы. Тогда процедура ПриСозданииПриЧтенииНаСервере будет выглядеть так
Из процедуры ПриСозданииПриЧтенииНаСервере можно выделить всю легкую клиентскую логику в процедуру НастроитьЭлементыФормы с директивой НаКлиентеНаСервереБезКонтекста. Такую легкую и доступную во всех контекстах формы процедуру можно звать при большинстве изменений реквизитов, которые должны менять косвенно связанные элементы формы.
Пример модуля управляемой формы
Обычная форма
В обычной форме благодаря наличию события ПриИзмененииДанных логику обновления формы можно помещать прямо в его обработчик. Здесь также стоит вынести всю легкую логику в процедуру НастроитьЭлементыФормы по аналогии с управляемой формой.
Пример модуля обычной формы
Применяю данную методику уже много лет.
Прикладываю выгрузку демонстрационной базы, где на примере справочника и регистра сведений показаны все описанные в статье проблемы и сама методика.
ITNote
Записка по работе в 1С с управляемой форме.
ЭтоНовый() в увправляемой форме
Наверх
Заполнение реквезитов
Для реквезитов в документеобработкеотчете:
Для реквезитов на форме:
Наверх
Получение пустой ссылки или предопределенного значения.
Наверх
Открыть форму
Наверх
Фунции отвечающие за обмен данных с формой на сервере.
Наверх
На сервере обратиться к функции находящейся в модуле объекта.
Пример для обработки. Функция в модуле объекта зовется ОбсчитатьДанные.
Наверх
Внешняя обработка: из модуля формы вызвать процедуру в модуле объекта
Наверх
ПолучитьМакет
Наверх
Получение расшифровки для текущей ячейки СКД
«Результат» — поле табличного документа.
Наверх
Обратиться к «видимым» строкам таблицы значения
На форме расположен таблица «табДанные». Берет данные из таблицы значения «тзДанные».
Имееться булевое поле «Выбран» которое надо проставить в Истина для тех строк которые видны после поиска.
Наверх
Получить данные из текущей строки таблицы
Таблица «ОтклонениеПоВыручке» ссылаеться на одноименную табличную часть в документе.
1С 8.2 УП : Последовательность событий при открытии формы нового элемента
Последовательность событий, которые происходят при открытии формы нового элемента, можно представить следующей схемой:
Прежде всего, при заполнении нового объекта данными, можно попробовать обойтись вообще без написания какого-либо кода. Для этого у реквизитов объектов конфигурации есть свойства ЗначениеЗаполнения и ЗаполнятьИзДанныхЗаполнения.
Эти свойства позволяют визуально (в конфигураторе) задать правила, по которым реквизит будет заполняться данными при создании нового объекта.
Если этих возможностей недостаточно, то тогда нужно использовать возможности встроенного языка.
Действия с данными объекта нужно выполнять в модуле объекта, в обработчике события ОбработкаЗаполнения. Этот событие возникает только при создании новых объектов, при открытии форм существующих объектов это событие не вызывается. Поэтому в нем не нужно узнавать, новый это объект, или нет. Нужно только описать алгоритм заполнения объекта данными. При этом следует учитывать, что это событие будет вызываться в нескольких случаях:
При этом параметр Основание, передаваемый в этот обработчик, может иметь различные значения в зависимости от того, каким образом создается новый элемент.
Например, он может иметь тип ссылки, если новый объект вводится на основании.
Или он может иметь тип Структура, если новый объект создается интерактивной командой из списка, в котором установлен отбор. В этом случае структура будет содержать значения элементов отбора этого списка.
Также этот параметр может иметь тип Неопределено, если новый элемент создается интерактивной командой из панели действий. То есть в своем алгоритме начального заполнения полезно анализировать этот параметр.
Что касается внешнего вида формы нового объекта, то им нужно управлять в обработчике события формы ПриСозданииНаСервере.
Это событие возникает и для новых, и для существующих объектов. Поэтому в нем нужно убедиться в том, что открывается форма именно нового объекта. Убедиться в этом можно проанализировав параметр формы Ключ.
Если объект новый, в этом параметре будет пустая ссылка. Если это существующий объект – в этом параметре будет ссылка на этот объект:
Если требуется выполнять какие-то действия в обработчике события формы ПриОткрытии, то в нем ситуация аналогичная, нужно анализировать параметр формы Ключ.
Для тех кто не хочет читать все что выше, код проверки на ЭтоНовый в Управляемом приложении:
Базовый принцип программирования управляемой формы в 1С
Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.
Введение
Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.
Все дальнейшие рассуждения будут о правой части иллюстрации, о том, как структурировать код модуля и какие принципы позволят реализовать эффективное клиент-серверное взаимодействие.
Обозначим проблему
Прошло уже несколько лет как новая версия платформы 1С активно используется и выпущено множество решений (конфигураций) как фирмой 1С, так и ее многочисленными партнерами.
Сложилось ли за это время у разработчиков единое понимание принципов клиент-серверного взаимодействия при создании форм, и изменился ли подход к реализации программных модулей в новых архитектурных реалиях?
Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Зачем нужна структура кода?
Почему существующий стандарт разработки от фирмы 1С не помогает?
Шаблоны проектирования или мудрость поколений
Примеры шаблонов в платформе 1С
Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
Сравните с принятым в v8.1 стилем.