validateField(),leave(),modified()

[Lanai]

Задача простая с первого взгляда (или на самом деле простая):

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

Знаю, что вариантов много, но все они не подходят по разным причинам. Хочется оптимально правильный вариант найти. Спасибо!

[lev]

Как вариант:
На таблице (не на форме, а именно на самой таблице) есть метод ModifiedField(), в котором можно перехватывать изменение полей, и выполнять определенные действия.

[ZVV]

Цитата:

Сообщение от Lanai

Задача простая с первого взгляда (или на самом деле простая):

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

Знаю, что вариантов много, но все они не подходят по разным причинам. Хочется оптимально правильный вариант найти. Спасибо!

Как вариант:
- Добавляете в таблицу поле "коментарий"...
- "при изменении некоторых полей в форме" требуете чтоб этот комментарий был заполнен (обязательный)
- при сохранении строки (на update(), например) сохраняете историю изменения с комментарием и чистите поле "комментарий" в целевой таблице.

PS Для реализации второго пункта можно инспользовать .orig() и validateWrite()...

[belugin]

еще вариант - в update датасурса перед супером сравнивать этих значения полей с предыдущими (orig) и запрашивать коммент на все сразу

[DSPIC]

Цитата:

Сообщение от belugin

еще вариант - в update датасурса перед супером сравнивать этих значения полей с предыдущими (orig) и запрашивать коммент на все сразу

Нет таких методов на датасорсе Есть write(), который по RecId условно расчепляется на update и insert

[petr]

Цитата:

Сообщение от belugin

еще вариант - в update датасурса перед супером сравнивать этих значения полей с предыдущими (orig) и запрашивать коммент на все сразу

Тут только надо быть осторожным. Если это write на датасорсе формы то все ок, если же метод update на таблице, то надо не забыть проверить текущий уровень транзакции, иначе при обновлении таблицы из кода внутри транзакции будет запущена форма для взаимодейсвия с пользователем, что категорически нельзя допускать.

Я однажды такую ошибку допускил и меня EVGL за это страшно отругал

Не повторяйте чужих ошибок...

[belugin]

Цитата:

Сообщение от petr

Тут только надо быть осторожным. Если это write на датасорсе формы

я имелл виду write на датасурсе формы.

[Lanai]

2 belugin: Коммент должен быть к каждому полю свой.

2 lev: Забыл сказать версия 2.5. В 2.5 нет метода modifiedField() на таблице! Даже если бы и был, то не ясно какие именно действия нужно выполнить.

2 ZVV: Такой вариант допустим, но не хотелось бы например в справочнике клиентов создавать какое-то поле для временного хранения комментов - как-то не очень красиво. Но вариант!

2 DSPIC: Ща попробую - отпишу.

Всем спасибо за ответы!

[Lanai]

2 DSPIC: Попробовал! Во-первых код какой-то слишком большой получается (т.к. полей, которые нужно проверять около 15) - да и как-то не оптимально каждый раз проверять изменилось ли что-либо из них, но самое главное что validateWrite() вызывается один раз для всех полей - если например использовать для ввода комментария диалог, то после сохранения изменений в строке выскакивает сразу друг за другом несколько (столько, сколько полей мы изменили) диалоговых окон и не ясно куда какие комментарии вводить. Хотелось бы, чтобы запрос комментария выскакивал сразу после изменения поля (каждому полю свой).

[DSPIC]

1. Если это нужно сделать для конкретной формы, то лучше этот функционал написать на форме (а ещё лучше в классе и вызывать из формы). Если это нужно для таблицы, которая светится на нескольких формах, то лучше этот функционал написать на таблице, но при этом проверять, что вызов произошел из нужной формы, т.к. изменение полей таблицы может происходить не только по явной инициативе пользователя.
2. В примере данном примере вызов происходит на датасорсе формы Address, метод validateWrite():

public boolean validateWrite()
{
    boolean ret;
    Tutorial_RunbaseForm    tutorial_RunbaseForm;
    ;

    ret = super();

    if (ret && Address.RecId)
    {
        if (Address.Name != Address.orig().Name)
        {
            tutorial_RunbaseForm = Tutorial_RunbaseForm::construct();

            if (tutorial_RunbaseForm.prompt())
            {
                tutorial_RunbaseForm.run();
            }
            else
            {
                Address.reread();
                ret = checkfailed("ПОля не сохранены");
            }
        }
    }

    return ret;
}

Здесь проверяется на изменение поле "Name".
В качестве диалога\формы для указания причины изменения подставил диалог tutorial_RunbaseForm. У вас должен быть свой.

3. Это первый пример, который пришел в голову, соотв-нно на красивость и полную корректность не претендует.

[ZVV]

Цитата:

Сообщение от DSPIC

1. Если это нужно сделать для конкретной формы, то лучше этот функционал написать на форме (а ещё лучше в классе и вызывать из формы). Если это нужно для таблицы, которая светится на нескольких формах, то лучше этот функционал написать на таблице, но при этом проверять, что вызов произошел из нужной формы, т.к. изменение полей таблицы может происходить не только по явной инициативе пользователя.
2. В примере данном примере вызов происходит на датасорсе формы Address, метод validateWrite():

public boolean validateWrite()
{
    boolean ret;
    Tutorial_RunbaseForm    tutorial_RunbaseForm;
    ;

    ret = super();

    if (ret && Address.RecId)
    {
        if (Address.Name != Address.orig().Name)
        {
            tutorial_RunbaseForm = Tutorial_RunbaseForm::construct();

            if (tutorial_RunbaseForm.prompt())
            {
                tutorial_RunbaseForm.run();
            }
            else
            {
                Address.reread();
                ret = checkfailed("ПОля не сохранены");
            }
        }
    }

    return ret;
}

Здесь проверяется на изменение поле "Name".
В качестве диалога\формы для указания причины изменения подставил диалог tutorial_RunbaseForm. У вас должен быть свой.

3. Это первый пример, который пришел в голову, соотв-нно на красивость и полную корректность не претендует.

Всё бы хорошо, если б не одно "НО".
validateWrite() - идёт без транзакции, а сам update() потом пойдёт уже отдельной транзакцией
Соответсвенно потенциально имете проблему, когда лог вставился, а изменения не прошли.

Вариант belugin-а может и лишён конкретно этого недостатка (чего уже придираться то, кстати, - понятно же что он имел ввиду ), но в этом случае будет выскакивать запрос пользователю во время выполнения транзакции, что, я думаю все понимают, не есть гут..

[belugin]

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

[DSPIC]

Цитата:

Хотелось бы, чтобы запрос комментария выскакивал сразу после изменения поля (каждому полю свой).

А что, если юзер поменял, скажем, 5 полей, вбил причины и потом, не сохранив запись, передумал и нажал "Esc"? Думаю, так некорректно.
Тогда как предложение с т.з. пользователя:
При сохранении записи вываливается список модифицированных полей: форма(диалог) с гридом и полями в нём:
Имя поля Причина модификации

+ Кнопки OK\Cancel
Примерно так. Реализация на порядок сложнее, но решение можно сделать универсальным для любой таблицы...

[belugin]

Цитата:

Сообщение от DSPIC

А что, если юзер поменял, скажем, 5 полей, вбил причины и потом, не сохранив запись, передумал и нажал "Esc"?

Разумеется созхраняться комменты должны при сохранении записи а до этого где-то временно храниться

Правда тут надо озаботиться чтобы переход по записям не приводил к сохранению комментов на неправильной записи и т,д, _ вобщем тут я бы обязательно написал чеклист того, как это тестировать

[Андре]

Как вариант - доработать стандартное журналирование данных системы, добавив в журнал одно поле - 'примечание'. Не уверен, что оттуда получится выводить диалоговое окно для его ввода, но посмотреть в этом направлении можно.

Мы таким образом в журнал БД добавляли стек вызовов, изменивший данную запись в таблице.