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

var ControlName = GetByNameControlOnAdditionalTab("ControlName");
ControlName.AjaxEvents.Change.Event += ControlNameEditChange;

Но при компиляции ошибка что тип Terrasoft.UI.WebControls.Controls.BaseEdit не содержит метода AjaxEvents

Нравится

2 комментария

Здравствуйте, Эмин!
Свойства AjaxEvents действительно нет в классе BaseEdit, оно появляется в наследниках, например, TextEdit, потому что набор событий отличается для различных контролов.
Вашу задачу можно решить проще, сразу добавив все необходимые контролы и обработчики событий базовыми средствами, но сделать их невидимыми, а при загрузке страницы просто отображать нужные с помощью свойства "Hidden".

"Андрей Каспаревич" написал:

Здравствуйте, Эмин!

Свойства AjaxEvents действительно нет в классе BaseEdit, оно появляется в наследниках, например, TextEdit, потому что набор событий отличается для различных контролов.

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

С уважением,

Каспаревич Андрей

Эксперт 3-й линии поддержки


Андрей ,спасибо за ответ. Я знаю, что можно скрывать и показывать поля в зависимости от значения поля Категория. Наверное так и реализую.
Просто динамическое добавление полей уже реализовано в базовой версии BPM и мне показалось, что раз существует базовый способ менять наборы полей, то и обработчик для динамического контрола добавить тоже можно.

Показать все комментарии

В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.

Естественно самой реальной и первой причиной возникновения такой ошибки приходила идея о сбоях в работе событий полей окна редактирования (то есть значения в полях изменялись, а события данных полей(-я) не срабатывали).

В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица WindowLog, а вторая TriggerLog.

Первая таблица WindowLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Ответственный» (WindowsUser), «Имя поля породившего событие»(FieldName), «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для наполнения таблицы было использованы события невизуального компонента окна dlData: dlDataOnDatasetDataChange, dlDataOnDatasetBeforePost и dlDataOnDatasetAfterPost. В скрипте в событиях была создана функция, которая формировала SQL запрос к таблице WindowLog базы данных с фиксацией информации по указанным полям на момент срабатывания события.

Запрос:

INSERT INTO WindowLog (*набор полей*)
SELECT (*набор полей*) -- Dataset('поле1'), Dataset('поле2'), Dataset('поле2')

Вторая таблица TriggerLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Состояние» (до изменения записи и после), «SystemUser», «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для заполнения данной таблицы был создан триггер на инструкцию UPDATE проблемной таблицы с двумя запросами вставки значений в таблицу. В одном запросе вставлялись значения до изменений, а во втором после.

Запрос №1:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM deleted

Запрос №2:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM inserted

Результатом использования данного решения на основе анализа таблицы WindowLog было установлено, что срабатывают все события окна редактирования, влияющие на вычисление значения поля «Итого». В процессе использования окна редактирования и после сохранения записи значения поля «Итого» были корректны.

Проанализировав записи в таблице TriggerLog было установлено, что в результате выполнения инструкции UPDATE было внесено некорректное значение. Сопоставив даты создания записей в таблице TriggerLog и WindowLog было установлено, что инструкция UPDATE была вызвана не в результате манипуляций с окном редактирования, а иным источником. На основании поля «SystemUser» таблицы TriggerLog было установлено что изменения были внесены с помощью импортера данных.

Таблицу TriggerLog возможно расширить, добавив в нее поля, которые помогут ускорить процесс обнаружение источника изменений записи базы данных. Список дополнительных полей может выгладять следующим образом: ApplicationName, LoginName, HostName.

PS: Принимаю предложения на доработку вашей конфигурации!!! Для более детальной информации можно связаться по следующему e-mail адресу: providnui@ukr.net !!!

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

Всем удачи в этом не легком процессе!!!

Нравится

0 комментариев
Показать все комментарии