Методика обновления формы объекта данных при изменении объекта
Актуально для платформы 1С 8.2-8.3.17 (выше не проверял)
Под формой объекта данных в статье подразумевается форма ссылочного объекта (элемента справочника, документа и т.д.) или форма записи независимого регистра сведений.
Пусть в объекте есть строковый реквизит Наименование, длину значения которого мы хотим отображать на форме этого объекта. Добавляем в форму реквизит ДлинаСтроки типа Число и отображаем его в одноименное нередактируемое поле.
Также пусть в объекте есть реквизит типа ХранилищеЗначения, тип которого мы также хотим отображать в форме. Добавляем в форму реквизит ТипЗначенияВХранилище типа Строка и отображаем его в одноименное нередактируемое поле.
В каких же ситуациях нам потребуется обновлять эти косвенно связанные с объектом реквизиты?
Разумеется это нужно вызывать в событии ПриИзменении поля Наименование. А вот дальше многие ограничиваются только вызовом в ПриСозданииНаСервере[упр] и ПриОткрытии[обыч]. Тем самым они не учитывют
Примеры использования команды «Перечитать»
Случай 1
Объект данных, отображаемый в форме, мог быть изменен в БД с момента его загрузки в форму. Типичные способы таких изменений
Тогда при попытке начать изменение любого поля формы, напрямую связанного с данными (флаг «Изменяет данные»), пользователь увидит предупреждение «Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!»
Это результат срабатывания так называемой оптимистической объектной блокировки. Она гарантирует, что если пользователь изменяет объект, то его изменения не «затрут» изменения, сделанные другими сеансами или другими программными объектами этого же сеанса. И тогда, чтобы получить возможность редактировать объект, нужно будет его перечитать либо переоткрыть форму.
Случай 2
Пользователь изменил данные в форме и решил отменить сделанные изменения, но продолжить редактировать объект от его текущего состояния в БД.
В каких событиях обновлять форму?
Чтобы учесть все эти тонкости, нужно всю логику обновления косвенно связанных с объектом элементов формы поместить в процедуру ПриСозданииПриЧтенииНаСервере и вызывать ее из следующих обработчиков событий формы:
Управляемая форма
Обычная форма
Управляемая форма
В управляемой форме при открытии существующего объекта выполняются два обработчика: сначала ПриЧтенииНаСервере и затем ПриСозданииНаСервере. Поэтому процедура ПриСозданииПриЧтенииНаСервере будет вызываться 2 раза подряд и нужно не задублировать выполнение логики обновления формы. Элементы формы могут зависеть как от данных объекта, доступных через реквизит формы, так и от недоступных через него (реквизиты типа ХранилищеЗначений), которые доступны только одном из них (ПриЧтенииНаСервере). Поэтому в процедуре ПриСозданииПриЧтенииНаСервере надо предусмотреть оба вызова таким образом, чтобы при создании формы существующего объекта при ее вызове из ПриЧтенииНаСервере выполнилась только логика работы с хранилищами значений, а при последующем вызове из ПриСозданииНаСервере выполнилась только логика, зависящая от остальных данных объекта. При этом ее вызов из уже открытой формы (из ПриЧтенииНаСервере и ПослеЗаписиНаСервере) должен выполнять все действия. Для этого создадим в общем модуле функцию ЭтоВызовПослеОткрытияФормы, где будем проверять наличие параметра ТолькоПросмотр у формы. Тогда процедура ПриСозданииПриЧтенииНаСервере будет выглядеть так
Из процедуры ПриСозданииПриЧтенииНаСервере можно выделить всю легкую клиентскую логику в процедуру НастроитьЭлементыФормы с директивой НаКлиентеНаСервереБезКонтекста. Такую легкую и доступную во всех контекстах формы процедуру можно звать при большинстве изменений реквизитов, которые должны менять косвенно связанные элементы формы.
Пример модуля управляемой формы
Обычная форма
В обычной форме благодаря наличию события ПриИзмененииДанных логику обновления формы можно помещать прямо в его обработчик. Здесь также стоит вынести всю легкую логику в процедуру НастроитьЭлементыФормы по аналогии с управляемой формой.
Пример модуля обычной формы
Применяю данную методику уже много лет.
Прикладываю выгрузку демонстрационной базы, где на примере справочника и регистра сведений показаны все описанные в статье проблемы и сама методика.
Как обновить форму документа после изменения данных
хотела обновить реквизит измененный
УправляемаяФорма (ManagedForm)
ОбновитьОтображениеДанных (RefreshDataRepresentation)
Синтаксис:
Тип: ГруппаФормы; ТаблицаФормы; ПолеФормы; Массив.
Если параметр задан, то установка значений (и обновление) будет выполняться только для тех элементов, которые заданы в параметре. Если в качестве значения передан пустой массив, то ни для каких элементов формы установка значений выполнена не будет.
После вызова метода признак необходимости установки значений и обновления для элементов формы сбрасывается: если после вызова метода никакие данные формы не меняются, то ни для никаких элементов, кроме указанных, текст обновлен не будет.
Если параметр имеет значение типа Массив, то элементами массива могут быть только значения типа ГруппаФормы, ТаблицаФормы, ПолеФормы.
Если массив содержит значение другого типа, то будет выдано исключение о неверном типе параметра.
Вызов метода ОбновитьОтображениеДанных с параметром имеет смысл только внутри обработчика ВнешнееСобытие, обработчиков ожидания формы и обработчика ОбработкаОповещения.
В обработчиках других событий вызов этого метода с параметром аналогичен вызову без параметра (при необходимости данные будут установлены всем элементам управления).
Описание:
В принудительном порядке обновляет содержание элементов управления.
Полезен при изменении значений реквизитов формы вне формы, в тот момент, когда форма отображается на экране.
Тонкий клиент, веб-клиент, толстый клиент, мобильное приложение(клиент).
Примечание:
В веб-клиенте обновление элементов управления происходит не сразу, а после окончания выполнения кода на встроенном языке.
Программное изменение управляемых форм
Чтобы упростить разработку изменений формы, можно воспользоваться небольшой хитростью. Все изменения можно сначала внести на форму через конфигурирование и отладить доработку формы. После преобразовать программные изменения в код. Изменения, которые нужны в форме изначально, стоит вносить в процедуре «ПриСозданииНаСервере». Для внесения изменений лучше сделать отдельную процедуру (например, «ДополнитьФормуПрограммно») и вызывать ее в штатной процедуре «ПриСозданииНаСервере», тогда изменение типовой формы 1С будет выглядеть одной строчкой.
Согласитесь, обновить доработанную таким образом форму значительно проще, чем вручную сравнивать и вносить все изменения формы при каждом обновлении. Конечно при сильном изменении типовой формы, могут потребоваться правки в процедуре программного дополнения формы, но такие случаи довольно редкие. Если в ходе разработки изменилась типовая структура объекта, то добавлять новые реквизиты на форму нет необходимости. Эти реквизиты будут доступны по пути «Объект.НовыйРеквизит».
Но иногда нужно добавить реквизит формы. Например, «Статус документа», который будет заполняться из специального регистра при открытии формы. Добавить новые реквизиты можно, открыв в 1С табличный документ, управляемая форма изменяется через команду ИзменитьРеквизиты(«ДобавляемыеРеквизиты», «УдаляемыеРеквизиты»).
«ДобавляемыеРеквизиты» и «УдаляемыеРеквизиты» – это массивы с элементами типа «РеквизитФормы». Тут все просто – «Добавляемые» добавляются, «Удаляемые» – удаляются.
Функция РеквизитФормы («ИмяРеквизита», «ТипРеквизита», «Путь», «Заголовок») создает объект типа «РеквизитФормы».
Тут важно понимать, что «ИмяРеквизита» содержит имя без точек. То есть имя без пути реквизита. Если нужно добавить реквизит, например, табличной части объекта, то уже в реквизите «Путь» указать путь к ТЧ реквизита – «Объект.Товары». «ТипРеквизита» задается через объект «ОписаниеТипов». После программного добавления реквизитов на форму нужно добавить элементы на форму или изменить свойства текущих. Для добавления новых элементов на форму есть два метода:
-Элементы.Добавить(«ИмяЭлемента», «ТипЭлемента», «Родитель»).
-Элементы.Вставить(«ИмяЭлемента», «ТипЭлемента», «Родитель», «Элемент»).
«ИмяЭлемента» должно быть уникальным в рамках элементов формы. Лучше добавить какой-то префикс, чтобы не возникло пересечений с типовыми элементами формы.
«ТипЭлемента» имеет не так уж много вариантов. Это «ПолеФормы», «ГруппаФормы», «ДекорацияФормы», «КнопкаФормы» и «ТаблицаФормы». Все остальные свойства назначаются через «Вид» создаваемого элемента. Например, поле с типом булево лучше сделать «флажком», установив вид элементу «ВидПоляФормы.ПолеФлажка».
В свойстве «Родитель» нужно указать группу или таблицу формы, в которую будет входить новый элемент. Также можно добавить элемент непосредственно на управляемую форму без подчинения другим элементам. Для функции вставить дополнительно указывается «Элемент», перед которым будет вставлен новый создаваемый элемент формы. Ну и конечно же, мало просто добавить элементы на форму. Система должна реагировать на действия пользователя с формой.
Для установки событий элементам нужно использовать процедуру УстановитьДействие («ИмяСобытия», «Действие»).
Получилась вот такая процедура программного заполнения управляемой формы:
Код для копирования:
Специальные предложения
Так оно вроде практически никогда не нужно, если я правильно понял. Плюс всегда можно выводить реквизиты на какую-то отдельную страницу если, например, не была найдена группа (программно) типовая, в которой она располагалась раньше. А вот с расширением сложнее. Я вот до сих пор не могу понять как быть в ситуации когда, например, наворотишь много изменений в одной форме или много форм в одной конфигурации, а потом при значительных изменениях типовой конфы оказывается значительно сложнее проанализировать все изменения и как-то удобно сравнить объединить. Получается даже больше работы.
И с другой стороны, как уже было подмечено, программные изменения влияют на кэширование форм. Приходится искать баланс)
Только из-за того, что расширение нельзя сравнивать с конфигурацией, у нас программное изменение формы.
После обновления запускается отладочная обработка, которая открывает все измененные формы. В коде создания есть ветки условия на отладку. Если не найден родитель или элемент перед которым нужно было разместить програмно-создаваемый (или если больше нет элемента, чьи свойства изменялись и т д.), оно информативно ругается через СообщениеПользователю. Плюсом условным оформлением подкрашиваются созданные поля. Было принято такое решение, потому что нельзя, чтобы добавленные элементы переезжали «в нарнию» и мы не знали об этом.
Я об этом читал, но когда сравнивал работу «до» и «после», разница была в 0.3 сек на самой дикоизмененной форме. (остальные с трудом набирают 0.01) Счел затраты оправданными. (Это форма сделки, она итак долго открывается, потому что при открытии проверяет бизнес-процесс на основании себя)
Когда все это хозяйство задумывал, хотел обработку, которая могла бы Сравнить типовую конфигурацию и основную. Планировалось выводить на форму дерево объектов формы (элементы, реквизиты и команды). В этом дереве подсвечивать добавленные объекты на форму в конфигураторе. Добавить команды, которые генерировали бы программный код создания этих изменений. Плюсом нужен был механизм сохранения настроек формы. Я выбрал xml. По плану в «ПриСозданииНаСервере» во временное хранилище помещается таблица со всем нужным, и дальше размещается на форме в виде дерева. А после генерации, настройки сохранялись бы в xml. (как оказалось, можно и без xml обойтись)
Собственно реализация оказалась дико сложной. Не все свойства элементов серилизуются, не все значения существуют на клиенте. иногда платформа без видимых причин просто падает в дамп (предполагаю, что остается связь значений свойств формы в этой ТЗ с формой которая после ПриСозданииНаСервере закрывается)
Поэтому я решил парсить выгрузку формы в файлы (вроде сразу xml и чего париться то, собирать что-то). Естественно это еще затратнее, а поддерживать еще затратнее).
Сейчас это просто 2 общих модуля, которые вызываются из СобытияФорм и СобытияФормКлиент.
Как настанет свободный промежуток, хочу сделать справочник, в котором будут храниться изменения форм (так же с отображением дерева объектов формы, но без сравнений с типовой). Общиймодуль с кэшированием, чтобы вся информация каждый раз не собиралась (Сначала собирается массив всего что нужно сделать с формой, а потом разом все это меняется). Это даст возможность из предприятия добавлять/изменять формы без нужды выгнать всех пользователей (Возможность применить изменения только по субботам 1 час, динамическое обновление не используем потому-что ужасы творит иногда)
И в планах сделать аналог патча. Добавить код, чтобы можно было вызывать определенные процедуры из внешней обработки, в случае косяка в процедуре команды или где-то еще.
1с 8 управляемое приложение. Обновить форму
Подскажите пожалуйста, как в коде написать аналог кнопки обновить форму. Судя по всему это не просто Прочитать() или ОтобразитьИзменениеДанных()
Обновить() не работает в управляемых формах
Расширение управляемой формы для справочника.Прочитать (Managed form extension for catalogs.Read)
Расширение управляемой формы для справочника (Managed form extension for catalogs)
Прочитать (Read)
Синтаксис:
Обновляет объект управляемой формы.
Тонкий клиент, веб-клиент, сервер, толстый клиент.
(18) В таблицу формы, отображающую ТЧ добавлена служебная колонка, которая заполняется по строкам при чтении на сервере. При записи документа извне были добавлены строки. (15) строки эти прочитает, да. А как же значение служебной колонки кто его заполнит и когда? Добавлять вызов заполнения после ЗначениеВРеквизитФормы? Это уже точно г-код.
P/s А Вообще-то это основы.
(19) ты предложил совсем другую задачу нежели объявлена автором.
Делать два серверных выхова при такой задачи это г-код
P/s А Вообще-то это основы.
Объясняю суть проблемы. Так как уже совсем запарилась. понимаю суть проблемы но не понимаю почему так.
Я понимаю что это из-за того что я записываю элемент справочника в котором ссылаюсь на текущий документ, но мне ведь это и надо.
Если нажать Обновить на форме документа то все становится хорошо. но ведь в период между записью документа и Действиями со справочником могли что-то изменить в самом документе и эти изменения не сохранятся а это совершенно не гуд
Обновление списков при интерактивных действиях пользователя
Область применения: управляемое приложение, мобильное приложение.
2. Команды, которые изменяют объекты и размещаются в форме списка, должны заботиться об обновлении списка объектов после своего выполнения. Например, после изменения одного объекта рекомендуется вызывать метод ОповеститьОбИзменении :
&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
При изменении нескольких объектов целесообразно обновлять список однократно, в конце операции:
&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
3. Также должно быть обеспечено обновление данных в динамическом списке, у которого не назначена основная таблица. Такие динамические списки могут отображать данные из нескольких таблиц.
3.1. Если данные добавляются или изменяются командой, расположенной в форме динамического списка, то необходимо обновить список явно после выполнения команды.
3.2. Если данные изменяются в какой-либо другой форме (например, в форме объекта), то необходимо организовать обновление списка через оповещение. Для этого в каждой форме объекта, данные которого выводятся в динамическом списке, следует реализовать обработчик события ПослеЗаписи с использованием метода Оповестить :
Оповестить («Запись_ «, ПараметрыОповещения, ОбъектСсылка);
Затем в обработчике события Оповещение в форме динамического списка разместить код по обновлению динамического списка вида:
&НаКлиенте
Процедура ОбработкаОповещения(ИмяСобытия, Параметр, Источник)
Если Врег(ИмяСобытия) = Врег(«Запись_РасходнаяНакладная»)
Или Врег(ИмяСобытия) = Врег(«Запись_НакладнаяНаПеремещение») Тогда
Элементы.СписокНакладных.Обновить();
КонецЕсли;
При этом имена событий следует проверять явным образом, чтобы исключить неоправданное обновление списка.
Оповестить(«Запись_РасходнаяНакладная», ПараметрыЗаписи, Неопределено);