Управление изменением записей на форме.

[pwp]

Цитата:

Сообщение от Владимир Максимов

При сохранении изменений должен сработать метод write() на DataSource формы. Если выбрано "Нет", то записи не произойдет и метод write() не сработает

Это верно, но как поймать ситуацию, что метод write и не вызывался при отмене ?

Цитата:

Сообщение от S.Kuskov

Методом научного тыка удалось установить, что данный бокс вызывается где-то в супере element.canClose(). Также удалось распознать нажатие кнопки 'Отмена': в этом случае super() метода canClose возвращает false, а соответственно для кнопок 'Да' и 'Нет' - true (что логично, т.к. при таком выборе форма должна закрыться).

Это правильно, но нужно знать что клиент нажал "НЕТ" и реагировать. Если "Да"-то
реакция не нужна. А тут и ДА и НЕТ не различаются!!
Можно, конечно, в task поймать Esc, откатить все что нужно и заменить его на ctrlQ-что вроде равно Esc c ответом "НЕТ".

[pwp]

Цитата:

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

Я что то не очень понял задачу...
Сейчас в стандарте, если ты что то изменил на форме, не сохранил и нажимаешь Esc, вылезает сообщение "В форме были сделаны изменения. Сохранить?" и три кнопки "Да", "Нет", "Отмена". Если нажать "да", то форма закроется и изменения сохраняться, если "нет", то форма закроется и ничего не сохраниться, если "отмена", то форма проста останется открытой и изменения остануться в том же виде не сохрененные.
У меня созается впечатление что вам ничего доделовать не надо, а просто нажать на кнопку да, что бы сохранить изменения.

Если это я, то да, но кто знает что нажмет оператор, если нажмет НЕТ, то кое что нужно откатить в данных....

[S.Kuskov]

Цитата:

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

Если это я, то да, но кто знает что нажмет оператор, если нажмет НЕТ, то кое что нужно откатить в данных....

А если свет выключится?

Помойму здесь явная ошибка в проектировании решения.

Не нужно откатывать по 'Нет', а нужно коммитить по 'Да'. Чуствуете разницу?

[pwp]

Цитата:

Сообщение от S.Kuskov

А если свет выключится?
Помойму здесь явная ошибка в проектировании решения.
Не нужно откатывать по 'Нет', а нужно коммитить по 'Да'. Чуствуете разницу?

То что тут ошибка в проектировании, это да, но я на это повлиять не могу. А вот что такое коммитить по Да - не пойму пока, уж извините... Если это выполнить то, что нужно было бы потом откатить, то вопрос: а если опер не нажмет ESC ? Лучше конечно тогда "коммитить" в validateWrite - но тут опять накладываются ошибки проектирования, а скорей постановки.

[Владимир Максимов]

Цитата:

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

Это верно, но как поймать ситуацию, что метод write и не вызывался при отмене ?

А зачем это надо ловить? Если пользователь вошел в форму, просто посмотрел ничего не изменяя и вышел. Эту ситуацию тоже хотите отлавливать? Ведь этот сценарий ничем не будет отличаться от нажатия кнопки "Нет" в диалоге.

Если у Вас что-то другое, то опишите ситуацию подробнее. Не выбранный Вами способ решения задачи, а саму задачу. Почему возникла необходимость перехватывать отмену модификаций?

[pwp]

Цитата:

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

почему вы решили что это ошибка? избыточность изначально заложена в систему. сначало раскажите какая перед вами стоит задача.

Цитата:

Сообщение от Владимир Максимов

А зачем это надо ловить? Если пользователь вошел в форму, просто посмотрел ничего не изменяя и вышел. Эту ситуацию тоже хотите отлавливать? Ведь этот сценарий ничем не будет отличаться от нажатия кнопки "Нет" в диалоге.
Если у Вас что-то другое, то опишите ситуацию подробнее. Не выбранный Вами способ решения задачи, а саму задачу. Почему возникла необходимость перехватывать отмену модификаций?

Я думаю, задача представляет узкосудебный интерес. Ну хорошо. Журналы InvetJournalTable+InvetJournalTrans(Строки). Нужно, чтобы строки одного журнала имели одну дату. Для этого решили эту дату внести в Table (уже неверно). И при изменении поля клиентом в Table необходимо поменять дату и в строках. Решил: в validate этого поля на DS в Table тут же спросить клиента и при ДА заменить дату и в Table и в Trans. Все работает, но: если клиенту придет в голову нажать Esc вместо Save и там отказаться от модификации , то даты разъедутся. Вот и вся проблема(мелочи я опускаю).

[Владимир Максимов]

Цитата:

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

Журналы InvetJournalTable+InvetJournalTrans(Строки). Нужно, чтобы строки одного журнала имели одну дату. Для этого решили эту дату внести в Table (уже неверно). И при изменении поля клиентом в Table необходимо поменять дату и в строках. Решил: в validate этого поля на DS в Table тут же спросить клиента и при ДА заменить дату и в Table и в Trans. Все работает, но: если клиенту придет в голову нажать Esc вместо Save и там отказаться от модификации , то даты разъедутся. Вот и вся проблема(мелочи я опускаю).

Ошибка не в том, что Вы создали общую дату в шапке документа (это как раз нормально), а в том, что Вы выполняете некую модификацию в Validate(), что принципиально неверно!

Validate() не должен ничего изменять. Его цель - это всего-лишь верификация. Контроль корректности внесенных изменений.

Собственно, отсюда и Ваши проблемы. Я уже указал, меняйте в событии write() на DataSource-формы или (как уже сказали) в табличных методах update(). Т.е. в тех методах, которые, собственно, и предназначены для модификации.

Другая Ваша ошибка - это диалог с пользователем.

Практика показывает, что пользователи диалоги не читают! У них другая задача. Им надо ввести документ. Срочно! Еще вчера! Если интерфейс позволяет это сделать, нажав кнопку "Да"/"Нет", то они и будут нажимать кнопки не обращая внимания на текст. Тем более, в Вашем случае совершенно не важно, какую кнопку они нажмут.

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

[pwp]

Цитата:

Сообщение от Владимир Максимов

Ошибка не в том, что Вы создали общую дату в шапке документа (это как раз нормально), а в том, что Вы выполняете некую модификацию в Validate(), что принципиально неверно!!
Validate() не должен ничего изменять. Его цель - это всего-лишь верификация. Контроль корректности внесенных изменений.

Возможно, Вы правы.

Цитата:

Сообщение от Владимир Максимов

Другая Ваша ошибка - это диалог с пользователем.
Практика показывает, что пользователи диалоги не читают! У них другая задача. Им надо ввести документ. Срочно! Еще вчера! Если интерфейс позволяет это сделать, нажав кнопку "Да"/"Нет", то они и будут нажимать кнопки не обращая внимания на текст. Тем более, в Вашем случае совершенно не важно, какую кнопку они нажмут.
Вы должны жестко "прошить" правила, когда измененная дата приводит к изменению даты во всех строках журнала. Возможно, создать дополнительные настройки или настроечные таблицы. Никакого диалога с пользователем быть не должно!

Здесь есть возражения. То, что не читают-верно и жмут подряд. Но сам факт вопроса должен быть, иначе Вам скажут, что не хотели менять дату, а она сама поменялась. Просто по умолчанию должно все отработать по норме.
"Прошить" правила...без диалога вряд ли получится, клиент ведь может ввести и неправильную дату(например 01.01.2010 вместо 05.01.2010), которую по таблицам не отследить, И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

[Владимир Максимов]

Цитата:

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

То, что не читают-верно и жмут подряд. Но сам факт вопроса должен быть, иначе Вам скажут, что не хотели менять дату, а она сама поменялась. Просто по умолчанию должно все отработать по норме.
"Прошить" правила...без диалога вряд ли получится, клиент ведь может ввести и неправильную дату(например 01.01.2010 вместо 05.01.2010), которую по таблицам не отследить,

Вы уж определитесь. Если согласны с тем, что "не читают", то какая разница, какой именно вопрос Вы зададите? Все-равно ведь не прочитают

Если Вы считает, что факт наличия вопроса как-то поможет Вам при "разборе полетов", то не обольщайтесь. Возможно, перед руководством Вы и сможете себе обезопасить, но данные-то все-равно получатся кривыми. Задавали Вы вопрос или нет. Ведь не читают же! Да и исправлять-то кому? По любому, лишние проблемы для СЕБЯ!

Здесь возможен только отказ в изменении. Но никаких диалогов!

Цитата:

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

И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

Ну, и настаивайте на этом решении. Объясните консультанту всю глубину его заблуждений

[S.Kuskov]

Цитата:

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

И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

Кстати, никто не мешает вам сделать это. Тем самым вы решите свою проблему централизации источника изменений. Но вопросу совместимости вашего кода по смене даты со стандартным кодом стоит уделить максимум внимания. Я бы сказал встаёт вопрос не где делать изменения, а как их делать.

[pwp]

Цитата:

Сообщение от Владимир Максимов

Вы уж определитесь. Если согласны с тем, что "не читают", то какая разница, какой именно вопрос Вы зададите? Все-равно ведь не прочитают
..........................
Здесь возможен только отказ в изменении. Но никаких диалогов!

В общем это вопрос спорный и иделогический......Насчет диалога Вы меня не убедили.

Цитата:

Сообщение от Владимир Максимов

Ну, и настаивайте на этом решении. Объясните консультанту всю глубину его заблуждений

Я попробую, конечно, но нет уверенности, что будут слушать....Думаю, есть аксиомы, которые нарушать не следует. В частности - единственность источника данных- а она здесь нарушена - отсюда и проблемы. Причина в этом.Правда, никто из принявших участие, меня пока не поддержал на эту тему.

Цитата:

Сообщение от S.Kuskov

Кстати, никто не мешает вам сделать это. Тем самым вы решите свою проблему централизации источника изменений. Но вопросу совместимости вашего кода по смене даты со стандартным кодом стоит уделить максимум внимания. Я бы сказал встаёт вопрос не где делать изменения, а как их делать.

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