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

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

Цитата:

Сообщение от 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. Но поскольку документации нет, нужно открывать исследования на эту тему с тестированием вариантов и построением стандартной методики работы. Стремно, конечно, исследовать такие вещи, но других вариантов не прослеживается.... В общем , по моему, эту тему можно закрывать. Спасибо всем, принявшим участие.