Механизм основных форм. Назначение обработчиков событий с помощью подписок на события Обработчик события открытия формы

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

• Записать
• Провести
• Провести и закрыть
• Отмена проведения

Действие Записать

1. Модуль объекта - перед записью (начинается транзакция, документ еще не записан);
2. Модуль формы (&НаСервере) - при записи на сервере (фиксация транзакции);

1. Модуль формы (&НаКлиенте) - перед записью;
2. Модуль формы (&НаСервере) - обработка проверки заполнения на сервере;
3. Модуль объекта - обработка проверки заполнения;
4. Модуль формы (&НаСервере) - перед записью на сервере;
5. Модуль объекта - перед записью (начало транзакции, документ еще не записан);
6. Модуль объекта - при записи (документ записан);
7. Модуль объекта - обработка проведения (формирование набора записей движений документа);
8. Модуль формы (&НаСервере) - при записи на сервере (записан набор записей движений документа, фиксация транзакции);
9. Модуль формы (&НаСервере) - после записи на сервере;
10. Модуль формы (&НаКлиенте) - после записи.

Последовательность выполнения событий при записи документа из формы, у которого запрещено проведение (свойство Проведение установлено в значение Запретить ) будет следующей:
В отличии от документа, у которого разрешено проведения, в этом случае отсутствует событие ОбработкаПроведения . Но, при записи проведенного документа с перепроведением и при записи документа, у которого запрещено проведение, кроме самой записи, в контексте формы и в контексте объекта вызывается также событие ОбработкаПроверкиЗаполнения . Это событие вызывается расширением формы для проверки заполнения реквизитов при записи или при проведении документа в форме.

Действие Провести

Действие Провести и закрыть

Действие Отмена проведения

1. Модуль формы (&НаКлиенте) - перед записью;
2. Модуль формы (&НаСервере) - перед записью на сервере;
3. Модуль объекта - перед записью (начало транзакции);
4. Модуль объекта - обработка удаления проведения (удаление движений);
5. Модуль объекта - при записи (движения удалены, документ записан);
6. Модуль формы (&НаСервере) - после записи на сервере (фиксация транзакции);
7. Модуль формы (&НаКлиенте) - после записи.

Программисту, имеющего немного опыта на платформе 1С 8.2, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта, а-а-а-а-аааа!!.....
Именно такое сложное чувство непонимания было поначалу и у меня. В процессе обучения и реального опыта была создана эта шпаргалка, целью которой было "разложить всё по полочкам", чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи объектов.

Для чего нам вообще нужны эти обработчики?
Очень часто программисту требуется переопределить стандартное поведение системы во время записи объектов, а именно: отменить запись, в случае каких-то условий; запросить дополнительную информацию у пользователя; дозаполнить реквизиты; что-то ещё записать в базу данных на основании этой записи; что-то изменить на форме после записи и т.д. и т.п. Каждый программист рано или поздно сталкивается с подобными задачами, потому знать назначение и последовательность запуска этих событий программисту, работающему на платформе 1С 8.2, необходимо.

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

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

Как выбрать конкретный обработчик?
Выбор зависит от поставленной задачи. Что конкретно можно делать в каждом обработчике опишу ниже, а пока пример.

Пример выбора обработчиков событий записи объекта:
Бывают задачи, когда потребуется использовать несколько обработчиков для решения одной задачи. Например, надо запросить информацию у пользователя во время записи: «Будем создавать новый документ на основании этой записи?» и, если пользователь ответит утвердительно, то надо создать новый документ с ссылкой на записываемый объект. Причем запись нового документа надо выполнять в транзакции, т.к. если текущая запись по каким то причинам будет отменена, то и уже созданный и записанный документ не должен остаться в базе данных.
Для решения этой задачи потребуется использовать обработчики события модуля формы по двум причинам:
1) Диалог с пользователем возможен только на клиенте, а клиентеские обработчики есть только в модуле формы. Для диалога будем использовать клиентскую процедуру модуля формы ПередЗаписью(), и сохраним ответ пользователя в параметре этой процедуры «ПараметрыЗаписи».
2) А в процедуре ПриЗаписиНаСервере() модуля формы примем этот параметр и в зависимости от него будем создавать документ или нет. Почему именно эта процедура? Ссылка будет получена только после записи, но поскольку нам нужно записывать в транзакции, то нужно использовать процедуры ДО завершения транзакции, но уже имеющие ссылку на записываемый объект. ПередЗаписью() не подходит, так как ещё нет ссылки, а ПослеЗаписи() не подходит, так как транзакция уже завершена. Остаётся ПриЗаписи(), но перед нами встаёт выбор: модуля формы или модуля объекта? Поскольку обработчик события ПриЗаписи() модуля объекта не содержит параметр, содержащий ответ пользователя, а событие ПриЗаписиНаСервере() модуля формы содержит, то ответ очевиден-используем это событие ПриЗаписиНаСервере() модуля формы потому что:
1) Это событие выполняется в транзакции 2) Содержит параметр «ПараметрыЗаписи», в котором уже содержится ответ пользователя, который передался из процедуры ПередЗаписью() 3) Ссылка уже создана и можно создавать новый документ, используя эту ссылку.

Ну и теперь последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности:
Во многих обработчиках есть параметр «Отказ». Там, где этот параметр присутствует означает, что в этом обработчике ещё можно отказаться от записи, присвоив параметру «Отказ» значение Истина, и тогда запись произведена не будет.
1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)
Выполняется на клиенте!
Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.
Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои.
Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, при записи регистра сведений, надо сделать запись в другой регистр сведений старое значение ресурса. Можно передать старое значение в эти самые параметры и уже в ПриЗаписиНаСервере сделать запись в другой регистр.
2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)
Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»)
И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.
Таким образом, можно сказать, что эти два обработчика событий предназначены:
Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»
Имеется несколько особенностей, которые необходимо учитывать:
Если у формы из которой записывается объект в свойствах не установлено «ПроверятьЗаполнениеАвтоматически», то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
Для документов, имеющих возможность проведения, эти события проверки заполнения вызываются только при проведении!
Оба эти события выполняются на сервере, отличие в том, что ОбработкаПроверкиЗаполненияНаСервере() это событие модуля формы и, следовательно, есть доступ к данным формы. А ОбработкаПроверкиЗаполнения() - событие модуля объекта.
4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки. Есть доступ к данным формы. Есть параметр ТекущийОбъект.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан.
Начало транзакции
5) Модуль объекта ПередЗаписью(Отказ)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки.
Для документов в параметры данного обработчика добавляются ещё два параметра:РежимЗаписи, РежимПроведения.
Запись
6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.
Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)
Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.
Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для новых объектов.
Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике.
7) Модуль объекта ПриЗаписи(Отказ)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.
Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.
Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый.
8) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи. Есть доступ к данным формы. Есть последний шанс отказаться от записи.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Можно обратиться к его свойствам и методам.
Завершение транзакции
9) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
Выполняется на сервере.
Можно использовать для того, чтобы визуально что-то отобразить на форме.
10) Модуль формы ПослеЗаписи(ПараметрыЗаписи)
Выполняется на клиенте!
Можно использовать для того, чтобы визуально что-то отобразить на форме или выдать предупреждение пользователю.

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

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

Стандартное поведение

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

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

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

При записи элемента справочника, будь то новый элемент или существующий, вызываются три обработчика: "ОбработкаПроверкиЗаполнения" (на этом этапе обработчик может проверить корректность введенных данных и в случае, если есть ошибки, отказаться от записи), "ПередЗаписью" (пока объект не записан в базу можно корректировать значения реквизитов и проверить какие-либо дополнительные условия) и затем "ПриЗаписи" (запись в базу произведена, но транзакция не закрыта, разработчик может проверить данные после записи и при необходимости отменить транзакцию).

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

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

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

Недокументированная сторона

Теперь рассмотрим интересную ситуацию. Допустим, для нашего справочника "ПростойСправочник" определены три подписки на событие "ПередЗаписью":

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

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

Отступление

Вы спросите: "Для чего создавать несколько подписок для одного события объекта конфигурации?". Ответ прост. Если разработкой занимаются несколько человек, то вмешательство в созданные механизмы друг друга может привести к некорректной работе программы. В таких случаях самым логичным будет создавать отдельные подписки на события каждому разработчкику в соотетствии с поставленной задачей. Конечно, не исключено, что в дальнейшем они будут объединены в единую процедуру-обработчик.

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

Проанализировав отзывы пользователей, разработчики в восьмерке реализовали новый объект, получивший название «Подписка на событие». В этой статье мы постараемся раскрыть:

• Настройку подписок;
• Создание;
• Особенности функционирования.

Создание новой подписки

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

Находится эти элементы в ветке дерева «Общие» (Рис.1).

Для добавления нового обработчика необходимо:

Рис.3

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

Особенности функционирования подписок

Одним из главных вопросов, возникающих у пользователей начинающих работать с объектом «Подписка на события», является вопрос о порядке вызова процедур. Зачастую именно здесь кроются ошибки, связанные с тем, что процедура не срабатывает или срабатывает через раз.

На примере процедуры ПриЗаписи() для любого документа можно увидеть порядок вызова обработчиков.

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

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

Таким образом, последовательность обработок можно задать следующей схемой:

1. Обрабатываются события модуля объекта;
2. Обрабатываются подписки, связанные непосредственно с текущим типом данных;
3. Отрабатывается код, привязанный к общему типу.

Очень важно запомнить, что ни в коем случае в процедуры, исполняемые при записи, при проведении нельзя вставлять код, меняющий данные объекта-источника, это может привести к ненужному зацикливанию. Лучше подобный код использовать в процедурах ПередЗаписью.

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

Возрастающая популярность управляемых форм, используемых в 8 версии программы, а так же проблемы связанные с обновлением этих объектов с сохранением собственных изменений, привели к тому, что, начиная с платформы 8.2.15, в программе появилось событие ОбработкаПолученияФормы. Именно сюда можно вставлять код, изменяющий и заменяющий типовые формы.

Некоторые особенности данного обработчика:

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

Важно учитывать, что эта подписка вызывается не для конкретного объекта, а для его менеджера, то есть поле источник должно содержать это слово (Рис.4)

Рис.4

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

Когда пользователь нажимает на ту или иную кнопку, открывается или закрывается форма, записывается документ – возникает событие.

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

Как это сделать?

Подписки на события 1С

Подписка на события 1С – это , он находится в ветке конфигурации Общие/Подписки на события 1С.

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

Добавим новую подписку на событие 1С, установим название.

В свойстве подписки на событие 1С Источник – нужно выбрать один или несколько документов, справочников – объектов, на которые мы ставим обработчик.

В свойстве подписки на событие 1С Событие – нужно выбрать один из вариантов стандартных событий, которые могут произойти с выбранными документами и справочниками.

Мы упрощаем говоря «документы и справочники» — на самом деле можно использовать многие объекты 1С. К сожалению, нельзя подписаться на события 1С формы – например, при открытии формы, о чем жалеют многие программисты.

Набор возможных событий зависит от объекта. Будьте внимательны, так как если выбрать несколько (множество) объектов – то в списке событий будут только те события, которые могут быть у каждого из выбранных объектов (то есть общие для всех выбранных объектов события).

После этого остается создать функцию обработчик. Для этого в конфигурации должен быть с установленной в свойствах галочкой Серверный. При нажатии кнопки «лупа» будет создана функция – обработчик.

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

Для того, чтобы отказать в записи документа, если проверка прошла отрицательно, нужно установить параметр функции