Нужно определить что поле в Grid изменилось

Буферизацию не предлагать.

Есть какие идеи?

forum.foxclub.ru

и тред весь прочти.

InteractiveChange контролла в соответствующей колонке. Если табличка небольшая и нужен какой-нибудь банальный подсчет итогов, можно в лоб через AfterRowColChange

Вредный совет: контрольную сумму записи, или всего курсора, посчитай, на основе SYS(2017), до запуска Grid и по выходу из Grid, сравни, если были изменения, значит что-то изменили. Точность метода 146% 1-2^-32

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

ZenTigra
Нужно определить что поле в Grid изменилось

Это невозможно сделать, т.к. в гриде данные не хранятся
Как вариант (при выключенной буферизации), можно подсчитать контрольные суммы строк и сохранить в курсоре, в нужный момент произвести сравнение контрольных сумм сохраненных записей и текущих.





Исправлено 1 раз(а). Последнее : Влад Колосов, 07.07.15 18:59

h.i.a.
InteractiveChange контролла в соответствующей колонке.

Спасибо, для моей задач этого вполне хватило, уже все работает

PS.Нужно напомнить пользователю о том что он изменил некоторые данные, а сохранить забыл...

А если так:
в When пропишем
this.Tag = this.Value
а в Valid
IF this.Value # this.Tag
...
ENDIF

ZenTigra
PS.Нужно напомнить пользователю о том что он изменил некоторые данные, а сохранить забыл...

Например кинь на форму кнопку Caption="Сохранить"
Свойство Enabled = .F.
При изменении данных и при наличии буферизации в InteractiveChange
А при закрытии формы смотри в каком состоянии находится данная кнопка.
События формы QueryUnload, Release

Использовать Enabled или там Visible каких-то контролов для хранения инфы о том что "были изменения" - это более чем кривое решение.

Отслеживание в Valid (путём сравнения с "ранее запомненным в Tag значением") тоже имеет серьёзные изъяны: Отслеживать факт наличия изменений ДО выхода из поля нельзя - скажем если та же кнопка "сохранить" находится на тулбаре, или это вообще пункт меню, то пока не перейдёшь на ДРУГОЙ контрол то "сохранение" будет недоступно (это напрягает пользователя - он же ВВЁЛ данные - а оно "не фурычит"). Кроме того Tag это вообще-то символьное свойство, и придётся переводить все возможные типы данных в строку, если использовать именно Tag (и не забывать про правила сравнения строк - на что влияет SET EXACT, SET COLLATE). Если же помимо всего прочего используется буферизация, то изменение "Вася" на "Вася" (типа помурыжили поле а потом вернули всё назад) таким способом НЕ отслеживается, а вот статус записи в буфере будет "изменённая" - что, естественно, будет иметь МАССУ самых разных последствий - например невозможность перезапросить курсор т.к. в нём "висят" несохранённые изменения.
Т.е. это вариант, конечно, - но для весьма специфических требований.

Каков вопрос - таков и ответ.

У меня у контролов кроме св-ва Value есть OldValue.
На Gotfocus
.Oldvalue = .Value

Топику уже два года, но тогда мне не удалось красиво решить проблему, и я сделал по старинке, так как умею...

Но мне опять пришлось возвратиться к этой идеи.

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

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

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

Посему вопрос, как ПРАВИЛЬНО в Grid обработать попытку пользователя перейти на следующую запись, и перед этим спросить его, "Сохранить/Отменить изменения?"

ZenTigra
Посмотрите в сторону TasTrade, для универсального справочника это решение может оказаться вполне достаточным.

ZenTigra
Посему вопрос, как ПРАВИЛЬНО в Grid обработать попытку пользователя перейти на следующую запись, и перед этим спросить его, "Сохранить/Отменить изменения?"

Зачем это делать "при переходе на следующую запись"? Если ты хочешь управлять сохранением на уровне одной записи, то следует использовать "карточную" форму, а не грид. Грид предполагает "многозаписное" сохранение и соответственно 5-й режим буферизации.
Нет, ты конечно же можешь проверять в BeforeRowColChange "куда собрался пользователь" и соответственно спрашивать его про изменения и сохранять или отменять их, и даже "блокировать перемещение" через NODEFAULT - но как раз для "простых справочников" это будет весьма неудобно (для пользователя). Слишком много вопросов...
Буферизацию в любом случае следует использовать 5-ю. Наличие несохранённых изменений (что при "позаписном" сохранении, что при работе "всем скопом") показывает функция GetNextModified(0) - если возвращает не 0, значит есть изменённые записи.
Сохранять изменённые записи лично я предпочитаю в "ручном" цикле по одной за раз (цикл как раз с использованием функции GetNextModified() - по очереди ходя по модифицированным записям) - с контролем успешности (tableupdate возвращает .t.) сохранения каждой записи.
На самом деле для "плоского" справочника (одна таблица) это не обязательно - можно и через tableupdate(1 или даже 2) попытаться сохранить все изменения - тут фокс сам будет крутить подобный цикл "по изменениям". Проблемы будут лишь при сохранении сложных структур - более одной связанной таблицы (типа шапка/строки или родитель/дети), что относительно редко встречается для "справочников", но весьма часто для "рабочих" таблиц. Там логика сохранения должна быть гораздо более сложной (чтобы не нарушать целостность данных "в процессе", и не вызывать ложного срабатывания проверок этой самой целостности)...
Да, и не забывай что добавление записей (равно как и их удаление) это ТОЖЕ операция модификации. Особенно неприятно будет выглядеть "двойной" запрос - "вы хотите удалить запись", а потом сразу же "вы хотите сохранить изменения".
В общем у меня лишь в сложных случаях "попытка сохранения" инициируется перемещением по строкам в гриде - для "простых" случаев только явные нажатия на кнопку сохранения, либо же попытка закрытия формы.

Ну и как возможный альтернативный вариант - не делать вообще редактирования в гриде, вызывать для этого отдельную карточную форму (грид - только навигация/поиск, удаление записи - ну и инициирование операций "изменить запись", "добавить запись" - они в свою очередь вызывают форму с обычными полями, и уже там будут кнопки "Сохранить" или "Отменить")...

ZenTigra
Посему вопрос, как ПРАВИЛЬНО в Grid обработать попытку пользователя перейти на следующую запись, и перед этим спросить его, "Сохранить/Отменить изменения?"

Правильно - это НЕ СПРАШИВАТЬ!

Аксиома - пользователи сообщения НЕ ЧИТАЮТ! От слова "совсем"! Им работать надо! Данные вводить! У тут какие-то "левые" сообщения выскакивают. Если можно нажать "Ок" и введенные данные сохраняться, то пользователи так и сделают! НИЧЕГО НЕ ЧИТАЯ!

Сообщения должны только и исключительно информировать о какой-то ошибке. Не надо ничего у пользователя спрашивать! Это, во-первых, бессмысленно, а, во-вторых, опасно! А вдруг он ответит

Если же это на "поиграться", то

1. На таблицу устанавливается табличная буферизация (4 или 5)
2. В событии Grid.BeforeRowColChange/Grid.AfterRowColChange отслеживается попытка перейти на другую запись (перейти с Grid на другой объект, закрыть форму). Выполняется проверка факт изменения текущей записи. Далее сброс буфера одной этой записи, если необходимо

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

Igor Korolyov
Ну и как возможный альтернативный вариант - не делать вообще редактирования в гриде, вызывать для этого отдельную карточную форму (грид - только навигация/поиск, удаление записи - ну и инициирование операций "изменить запись", "добавить запись" - они в свою очередь вызывают форму с обычными полями, и уже там будут кнопки "Сохранить" или "Отменить")...

+1000
Тем более сам сказал, все справочники похожи. Значит и форму редактирования, можно сделать одну

Та в том то и дело, что справочников много, я уже 38 штук насчитал, и для каждого сделаны две формы, одна с Grid для выбора, а другая для редактирования, но почти все справочники чем то отличаются 2-3 полями, вот и решил попробовать их в самом Grid редактировать.
(еще нужно минимум 20 сделать, и не охота постоянно с этим возиться). Вот и захотел сделать одну универсальную форму для справочников
На ней разместить Grid (ReadOnly=.T., для защиты от Юзверов) и панель управления с стандартными кнопками добавить, редактировать, сохранить и отменить...
При нажатии на кнопку "редактировать" Grid переходит в режим ReadOnly=.F. и подсвечивается строка которую будут редактировать, а при попытке перейти на другую строку запрашивать о сохранении/отмене...

А что это будет неудобно?

PS.Ну допустим авто сохранения я сделаю по умолчанию, отмену по кнопке, но неужели сама идея редактирования в Grid ущербная?



Исправлено 1 раз(а). Последнее : ZenTigra, 24.04.17 13:25

ZenTigra
Та в том то и дело, что справочников много, я уже 38 штук насчитал, и для каждого сделаны две формы, одна с Grid для выбора, а другая для редактирования, но почти все справочники чем то отличаются 2-3 полями, вот и решил попробовать их в самом Grid редактировать.
(еще нужно минимум 20 сделать, и не охота постоянно с этим возиться). Вот и захотел сделать одну универсальную форму для справочников
На ней разместить Grid (ReadOnly=.T., для защиты от Юзверов) и панель управления с стандартными кнопками добавить, редактировать, сохранить и отменить...
При нажатии на кнопку "редактировать" Grid переходит в режим ReadOnly=.F. и подсвечивается строка которую будут редактировать, а при попытке перейти на другую строку запрашивать о сохранении/отмене...

А что это будет неудобно?

PS.Ну допустим авто сохранения я сделаю по умолчанию, отмену по кнопке, но неужели сама идея редактирования в Grid ущербная?

Нормальная идея, очень удобно, и ничего больше не нужно.
Разве что еще отдельный класс кнопок навигации для больших справочников не будет лишним.
Жаль, не сохранился у меня этот класс, обрывки черновиков где-то валяются, а то бы выложил.

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



Исправлено 1 раз(а). Последнее : lulgu, 24.04.17 13:36

ZenTigra
PS.Ну допустим авто сохранения я сделаю по умолчанию, отмену по кнопке, но неужели сама идея редактирования в Grid ущербная?

1. Для простого справочника - да ущербная.

2. Как бы ты не хотел, но для каждого справочника придётся делать свой класс/форму.

Можно облегчить себе "жизнь" - это у справочников сделать идентичные поля (типа ID, Name, Comment), тогда в классе/форме надо будет только подсунуть правильное имя таблицы/ХП.