Модифицированность() объекта (управляемое приложение)
Жизненный цикл формы объекта
Давайте рассмотрим, что происходит, когда мы открываем форму существующего элемента справочника.
На клиенте вызывается метод «ОткрытьФорму» или мы просто открываем форму из какого-либо списка справочника. Начинается серверный вызов
В памяти сервера создается новый СправочникОбъект, выполняется код модуля объекта (тот, что написан в самом низу модуля)
Данные объекта считываются из базы данных, присваиваются значения реквизитов, наполняются табличные части объекта СправочникОбъект.
В памяти сервера создается новая управляемая форма элемента
Вызывается событие формы ПриЧтенииНаСервере, куда передается свежесозданный СправочникОбъект в параметре ТекущийОбъект
Основной реквизит формы «Объект», тот, что в списке реквизитов выделен жирным шрифтом наполняется данными на основании данных СправочникОбъект. Здесь происходит обычное поэлементное присваивание свойствам объекта ДанныеФормы значений, записанных в одноименных свойствах объекта СправочникОбъект. По сути, происходит «ЗаполнитьЗначенияСвойств(ДанныеФормы, СправочникОбъект)
СправочникОбъект уничтожается. Все его данные стираются из памяти сервера.
Вызывается событие формы «ПриСозданииНаСервере», в котором мы получаем уже заполненные ДанныеФормы
Данные формы сериализуются и отправляются на клиента, где форма отображается пользователю
(5) а если поменяли на тоже самое?
я давным давно любил автоименования элементов в ПриОткрытии() загонять типа ФИО = Ф+» «+И» «+О
Модификация управляемых форм
1. Модификации управляемых форм
Подсистема модификации управляемых форм позволяет изменять свойства формы с помощью макета, который создается для каждой формы объекта метаданных или общего макета для общих форм. Для использования подсистемы необходимо перенести в свою конфигурацию модуль: ОбщийМодуль.МодификацияУправляемыхФорм Для применения к форме макета изменений, необходимо сделать вызов
Подсистема имеет защиту от повторного вызова, поэтому можно не беспокоиться о возможном вызове процедуры из общего обработчика
1.1. Формат описания изменений формы
Пример можно посмотреть в макете: Документ.Приход.Макет.МОД_Модификация_ФормаДокумента
Макет изменений состоит из 3-х областей, любая из которых не является обязательной, порядок расположения также не важен. Рекомендуется для каждой области использовать свой формат строк.
Допускаются следующие варианты :
1.2. Существующие ограничения:
2. Ограничение изменения реквизитов управляемой формы
Подсистема предназначена для ограничения измененения реквизитов управляемой формы на основании других реквизитов. Разные ограничивать доступ к реквизитам в зависимости от статусов или функциональных ролей. Ограничение рекомендуется делать при первом открытии формы и после каждой записи, т.к. нет смысла ограничивать реквизиты внутри одного сеанса работы с формой.
Для работы с механизмом необходимо добавить следующий фрагмент в раздел инициализации формы (после всех процедур и функций)
Ограничение выполняется с помощью вызова на клиенте:
По-умолчанию, если описание ограничений не указано, будут ограничен доступ ко всем элементам формы, связанных с данными объекта или реквизитами. В описании ограничений можно указать отклонение от этого правила с помощью настройки доступа к отдельным уровням дерева элементов. Например, для ограничения доступа ко всем элементам кроме поля «Утвержден» необходимо выполнить
По-умолчанию кнопки формы связанные с командами, у которых не установлен признак «ИзменяетСохраняемыеДанные» ограничиваться не будут, для их ограничения необходимо явно указать запрет, либо на кнопку, либо на все командную панель, например:
Для предоставления доступа ко всем элементам таблицы «Товары», сроме колонки «Цена» цена необходимо выполнить
Для предоставления доступа только к таблице «Проверка» необходимо выполнить
При необходимости восстановить ограничение доступа, измененное, например, в обработчиках разрешенных для редактирования реквизитов необходимо выполнить на клиенте или на сервере
Для отмены ограничения доступа необходимо выполнить на клиенте
Программная модификация управляемых форм
Одним из требований для прохождения аудита расширения в модели сервиса является программная модификация управляемых форм без заимствования самой формы в расширение.
Мы рассмотрим основные составляющие этой задачи: добавление реквизитов, добавление элементов формы и назначение обработчиков событий элементов формы.
Добавление реквизитов
Для добавления реквизитов используется метод объекта ФормаКлиентскогоПриложения
Реквизиты формы, добавленные через конфигуратор, удалить невозможно, поэтому второй аргумент процедуры можно не указывать.
Например, если мы создаем таблицу значений из двух колонок, то программный код для их создания будет выглядеть следующим образом:
Данную процедуру можно заимствовать в расширение, добавить проверку имени формы и вставить код изменения реквизитов:
Для остальных конфигураций придется переопределять другие процедуры. Например
Использование той или иной процедуры следует проверить в модуле редактируемой формы.
Изменение элементов формы
Для добавления нового элемента формы требуется передать в функцию Добавить данной коллекции имя элемента, его тип и родителя (при необходимости). Например:
При создании новых элементов формы старайтесь добавлять к их именам префикс своего расширения, чтобы избежать конфликтов с элементами формы типовой конфигурации. Этот же совет следует применять к именованию реквизитов формы, процедур, функций и глобальным переменным.
Обработка событий формы
Выполнить код по событию элемента формы можно двумя способами:
Для самых простых случаев (команда или событие без параметров) можно использовать следующие комбинации обработчиков и переопределяемых процедур:
При этом в предопределенной процедуре обязательно проверять имя команды (или имя элемента формы) и имя самой формы.
Либо вариант с использованием команд:
Полезные советы
Работа с динамическими списками
Переопределение открываемой формы
В некоторых случаях, когда требуется кардинальное изменение формы, следует не забывать о возможности переопределения открываемой формы в модуле менеджера объекта метаданных.
Данный метод следует использовать с осторожностью или ограничивать его использование ключами открытия формы, т.к. в этом случае мы делаем недоступной типовую форму.
Модифицированность()
Друзья, читаю в ПодпискеНаСобытие Перед записью Источник.Модифицированность(), и оно ВСЕГДА ИСТИНА.
Ничего не понимаю, данные не изменяются, как такое может быть?
1С 8.2 Управляемое Тонкий
Fragster
нет, проверял даже на Валюте, там всего-то 3 реквизита, в форме ничего не меняется. Модуль объекта абсолютно чист.
откуда берется модифицированность не понятно.
Перед запись в форме проверяю модифицированност формы = ЛОЖЬ.
У тебя есть ОбъектВФорме, ОбъектНаСервере. ОбъектВФорме модифицируется, а до ОбъектаНаСервере еще дело не дошло.
Копай ДанныеФормыВЗначение или что-то подобное.
Создал специально справочник вообще без реквизитов, объект все равно всегда модифицирован.
Похоже смотрит на версию объекта, а версия объекта всегда меняется при записи.
Жму, например, кнопку записать в форме 10 раз (в ней нет реквизитов вообще, одна кнока) и все 10 раз объект модифицирован.
Есть процедура «ПередЗаписью()» и она срабатывает всегда когда жмешь кнопку записать, не важно менял ты что=то или нет.
Но как в ней понять модифицирован объект или нет?
Проблема возникает только если записывать объект из формы.
Видимо на форму создается объект и латформа уже считает его модифицированным, т.к. он обратно в базу идет с клиента.
Если просто программнополучить объект и записать его, то Модифицированность() = ЛОЖЬ, если нажать на кнопку в форме, то будет ИСТИНА (хотя форма не менялась)
(10) подписка на событие геде выполняется, как думаешь?
НаКлиенте, али НаСервере?
Икогнито
Хватит глупости нести.
1)
Берем объект на сервере, суем его в форму на клиенте, открываем форму.
В форме ничего не меняем, ПередЗаписью() в форме МОдифифцированность формы = ЛОЖЬ, нигде нет никаких обработчиков, которые могли бы изменить объект. В подписке на события ПередЗаписью() сам объект МОдифицированность()=ИСТИНА (Почему, если ничего не менялось?)
PS:
Что я хочу я уже написал, читай 4 = «смысл проверки для версионирования. Выгружаю версию объекта в логи, если объект модифицирован. Всегда выгружать нет желания.»
(14) ты ваще не догоняешь в своем п. 2
Я тебя спрашивал: «Как объект может быть не модифицирован, если ты в форме жмешь кнопку «ЗАПИСАТЬ»?
Программная доработка форм, настраиваемая в режиме Предприятия
Однако во время обновления могут поменяться имена элементов формы, на которые завязаны наши программные доработки. В таком случае форма просто не откроется, и придется выводить emergency релиз. Имена элементов формы в типовых конфигурациях меняются регулярно, отследить это очень трудно. Собственно, доработка заключается в том, чтобы хранить в регистре сведений настройки доработок форм.
Создаем регистр сведений ДоработкиФорм
В дорабатываемой форме в процедуре ПриСозданииНаСервере добавляем одну строку:
Эта единственная строка кода, которую нужно будет поддерживать при обновлении.
Можно добавить ее в общую типовую процедуру, вызываемую из большинства форм, в таком случае форма останется полностью типовой.
Для БП 3.0 и в целом конфигураций основанных на БСП:
Также можно обрабатывать одно событие у программно добавленных элементов вообще без изменений:
Для УТ 10, КА 1, УПП 1: практически в любой форме есть метод ДействияФормыРедактироватьНомер(Кнопка), из него идет вызов МеханизмНумерацииОбъектов.ИзменениеВозможностиРедактированияНомера; указываем его в качестве обработчика нужного события, далее в общем модуле делаем что требуется
БП 3.0: Подключаемый_ВыполнитьКомандуПечати, остальное аналогично
Добавляем процедуру в серверный общий модуль (у меня называется ДоработкиФорм):
Что позволяет такая доработка:
1) Добавление/изменение элемента формы.
2) Добавление/изменение табличной части на форме.
3) Добавление/переопределение команды формы.
При этом форма остается полностью типовой, кроме одной строки в процедуре ПриСозданииНаСервере.
1) Добавить свой реквизит формы с обработчиком ПриИзменении
| ИдентификаторОбъектаМетаданных | Справочник1 (Справочник) |
| ИдентификаторОбъектаМетаданных | Справочник1 (Справочник) |
| ИмяФормы | ФормаЭлемента |
| ИмяЭлемента | «МойЭлемент» |
| Используется | Истина |
| Видимость | Истина |
| ТипЭлемента | «ПолеФормы» |
| Родитель | |
| ВидПоляФормы | «ПолеВвода» |
| ПутьКДанным | «Объект.НовыйРеквизит» |
| Заголовок | «Мой элемент» |
| ИмяКоманды | |
| ИмяТабличнойЧасти | |
| ИмяСобытия | «ПриИзменении» |
| Действие | «МойОбработчикКоманды» |
| ПередЭлементом | «ИмяСуществующегоЭлемента» |
2) Добавить свою табличную часть
| ИдентификаторОбъектаМетаданных | Справочник1 (Справочник) |
| ИмяФормы | ФормаЭлемента |
| ИмяЭлемента | «МояТЧ» |
| Используется | Истина |
| Видимость | Истина |
| ТипЭлемента | «ТаблицаФормы» |
| Родитель | |
| ВидПоляФормы | |
| ПутьКДанным | «Объект.НоваяТабличнаяЧасть» |
| Заголовок | |
| ИмяКоманды | |
| ИмяТабличнойЧасти | «НоваяТабличнаяЧасть» |
| ИмяСобытия | |
| Действие | |
| ПередЭлементом |
3)Добавить свою кнопку
| ИдентификаторОбъектаМетаданных | Справочник1 (Справочник) |
| ИмяФормы | ФормаЭлемента |
| ИмяЭлемента | «НоваяКоманда» |
| Используется | Истина |
| Видимость | Истина |
| ТипЭлемента | «КнопкаФормы» |
| Родитель | |
| ВидПоляФормы | |
| ПутьКДанным | |
| Заголовок | «Моя команда» |
| ИмяКоманды | «МойОбработчикКоманды» |
| ИмяТабличнойЧасти | |
| ИмяСобытия | |
| Действие | «МойОбработчикКоманды» |
| ПередЭлементом |
При таком составе ресурсов не получится создавать группы формы, страницы и переопределять несколько обработчиков. Я добавлял ресурсы по мере необходимости, надобности в других свойствах не было.Можно просто создать справочник НастройкиЭлементовФормы в который включить все нужные свойства, он будет единственным ресурсом.