Как в DBGrid отловить окончание редактирования ячейки?

← →
IceBeerg © (2004-12-01 18:14) [0]

собсвенно сабж

← →
Vemer © (2004-12-01 18:32) [1]

DbGrid отражает датасет. Dataset.AfterPost попробуй,
или DbGrid.dataSourse.Dataset.AfterPost - для маньяков )).

← →
IceBeerg © (2004-12-01 18:32) [2]

Vemer © (01.12.04 18:32) [1]
Спасибо, попробую.

← →
IceBeerg © (2004-12-01 18:40) [3]

Vemer © (01.12.04 18:32) [1]
Ну почти там...
Но это не помогает, мне надо по окончаню редактирования ячейки посчитать сумму по столбцу, но комманда post посылается только при смене строки.
Да, и еще вопрос, как установить куhсор в нужную строку DGGrid?

← →
msguns © (2004-12-01 18:47) [4]

>Vemer © (01.12.04 18:32) [1]
>DbGrid отражает датасет. Dataset.AfterPost попробуй,

Это событие возникает после того, как запостилась вся запись.
Если надо "поймать" узера на предмет проверки что он там понавводил и, если надо, "дать по рукам", то следует использовать:
TDataSet.BeforePost;
Если же требуется ловить непосредственно при попытке узера "свалить" из поля, куда он только что что-то ввел (по "гридному" говоря, из ячейки), то следует пользовать событие
TField.OnChange

← →
IceBeerg © (2004-12-01 18:49) [5]

msguns © (01.12.04 18:47) [4]
Буду пробовать TField.OnChange, но боюсь, что это не то, мне бы что-то на подобии onEditEnd - ну да, такого нет, но идея такая.

← →
msguns © (2004-12-01 18:50) [6]

>IceBeerg © (01.12.04 18:40) [3]
>Да, и еще вопрос, как установить куhсор в нужную строку DGGrid?

Как определяется "нужность" строки ?
Для установки курсора в датасете следует пользоваться методами навигации или поиска датасета.
И вообще надо бы определиться с понятиями. В гриде нет записей и полей, они есть в дата сете, который этот грид отображает. Как правили, приложение управляет именно датасетом (точнее его данными), а не гридом

← →
IceBeerg © (2004-12-01 18:55) [7]

msguns © (01.12.04 18:50) [6]
>Как определяется "нужность" строки ?
TTable.RecNo

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

← →
msguns © (2004-12-01 18:55) [8]

>IceBeerg © (01.12.04 18:49) [5]

Предупреждаю сразу, что если среди данных, отображаемых в гриде, есть даты, числа или дроби, то намаешься с прехватами и контролями.
Выхода 2:
1. Предоставить все непосредственно датасету и постирование делать в защищенном блоке без локализации ошибочного поля.
2. Выбросить на свалку привычку давать редактить в гриде и перейти к модальным формам с не DB-aware контролами. Все проверки делать либо по выходу из контролов либо комплексно при нажатии юзверем фишки "Записать". Рекомендуется как предпосылка перехода с TXXXTable на TXXXQuery

← →
Anatoly Podgoretsky © (2004-12-01 18:56) [9]

OnValidate

← →
msguns © (2004-12-01 18:57) [10]

>IceBeerg © (01.12.04 18:55) [7]
>>Как определяется "нужность" строки ?
>TTable.RecNo
>или мне просто перебрать все записи пока небудет найден нужный RecNo и там остаться? думал может, что проще есть.

Что значит "нужный RecNo" ? RecNo всегда (вернее не всегда, но в твоем случае точно) отображает номер текущей сзаписи датасета, а не строки грида.

← →
IceBeerg © (2004-12-01 19:00) [11]

msguns © (01.12.04 18:55) [8]
>2. Выбросить на свалку привычку давать редактить в гриде и перейти к модальным формам
Возможно этим и кончиться, но тем юзверям кому я это пишу можно давать возможность редактировать непосредственно DBGrid, так производительность будет выше.

Anatoly Podgoretsky © (01.12.04 18:56) [9]
Тоже буду пробовать.

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

← →
Alexander Panov © (2004-12-01 21:44) [12]

OnColExit

← →
Anatoly Podgoretsky © (2004-12-01 21:52) [13]

Alexander Panov © (01.12.04 21:44) [12]
Окончание редактирования ячейки не означает выхода из нее, надежен только validate.

← →
Anatoly Podgoretsky © (2004-12-01 21:53) [14]

Кроме того это событие возникает и без входа в режим редактирования.

← →
Alexander Panov © (2004-12-01 22:34) [15]

Anatoly Podgoretsky © (01.12.04 21:52) [13]
Окончание редактирования ячейки не означает выхода из нее

Это как при визуальном редактировании?

Anatoly Podgoretsky © (01.12.04 21:53) [14]
Кроме того это событие возникает и без входа в режим редактирования.

Достаточно перед этим обработать OnColEnter.

← →
Johnmen © (2004-12-01 23:03) [16]

>Alexander Panov © (01.12.04 22:34) [15]
>Достаточно перед этим обработать OnColEnter.

Кроме того это событие возникает и без входа в режим редактирования.

← →
Alexander Panov © (2004-12-01 23:10) [17]

Johnmen © (01.12.04 23:03) [16]
Кроме того это событие возникает и без входа в режим редактирования.

Используя временную переменную(OnColEnter) , проверяем, изменилось ли содержимое(OnColExit).

← →
Johnmen © (2004-12-01 23:31) [18]

>Alexander Panov © (01.12.04 23:10) [17]

Э-э-э... Не понял... Как проверяем, изменилось ли содержимое?

← →
IceBeerg © (2004-12-02 11:19) [19]

В связи с неожиданным нашествием стаи птиц типа "перепил" полевые испытания идей переносятся на завтра.

← →
Ну, я (2004-12-02 11:32) [20]

>msguns © [8]:
...Выбросить на свалку привычку давать редактить в гриде и перейти к модальным формам с не DB-aware контролами. Все проверки делать либо по выходу из контролов либо комплексно при нажатии юзверем фишки "Записать".

Господи, и здесь такие же маньяки, как на SQL.RU Да откуда вы беретесь такие???

>IceBeerg:
Покажусь банальным, но посоветую EhLib (поверь, многие вопросы, к-рые у тебя еще будут возникать, там решены :)))
Так вот - там элементарно довишь Column. OnUpdateData
ЗЫ: А еще можно словить текст, к-рый пользователь уже ввел в ячейку, но еще не записал в поле... и т.д.
ЗЗЫ: Впрочем, возможно это есть и в обычном гриде, но лучше все же перейти...

← →
msguns © (2004-12-02 11:58) [21]

>IceBeerg © (01.12.04 19:00) [11]
>>2. Выбросить на свалку привычку давать редактить в гриде и перейти к модальным формам
>Возможно этим и кончиться, но тем юзверям кому я это пишу можно давать возможность редактировать непосредственно DBGrid, так производительность будет выше.

Ты имеешь в виду редактирование колонки ? Типа в прайс-листе, когда юзверь корректит только одну колонку (цены), перемещаясь стрелками вверх-вниз ?
В этом случае, ИМХО, лучше работать через TClientDataSet, периодически сбрасывая изменения порциями. Так действительно будет шустрее и удобнее. Если же простое редактирование строк (типа как в фактуре накладной), то никакого повышения производительности от "гридного" редактирования не вижу, т.к. юзверь за один момент не может править более одной записи. Зато вот вероятность "проскакивания" фантомных изменений (это когда юзверь, например, нажал на кейпаде стрелку вниз, а при этом был выставлен NumLock и вместо перехода на след.строку ввелась цифра "8". А он не заметил и нажал другую кл., уйдя с откоррекченной записи. Прога же тупо пошлет постинг записи серверу.

>Ну, я (02.12.04 11:32) [20]
>Господи, и здесь такие же маньяки, как на SQL.RU Да откуда вы беретесь такие???

Из жизни, милейший. Помучившись с юзверями, привыкшими в "эксельной" технологии правки данных. Просто идеология организации данных в екселе и SQL серверах несколько отличается ;)
Зато когда юзверя переучил (переубедил), он существенно ответственнее отностися к своей работе вообще и к каждой операции (под операцией понимается манипуляции над объектом БД в целом, а не над какими-то его частями). Как следствие, резкое сеижение конфликтов и потерь данных и рост скорости и надежности работы всей системы.

← →
Ну, я (2004-12-02 12:16) [22]

msguns [21]:
А м.б. Вы все же обоснуете свой выбор более более аргументировано?

>>идеология организации данных в екселе и SQL серверах несколько отличается ;)

Кто-то утверждал обратное?

>>Помучившись с юзверями..

А м.б. не стоит их считать ...зверями? А м.б. просто писать так, чтобы людям было удобно, а не Вам?
Конечно, голова у программера болит меньше, когда он себе облегчает жизнь и заставляет всех остальных редактировать данные в модальных формах с не-DB control-ами?
В общем, пока доводов не увидел...

← →
Johnmen © (2004-12-02 13:14) [23]

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

← →
Ну, я (2004-12-02 13:17) [24]

Отрадно слышать, что не все такие упертые как msguns...
Я даже думаю, что их меньшинство!
PS: ну а пл теме топика - закрыта?

← →
Ну, я (2004-12-02 13:17) [25]

← →
Ну, я (2004-12-02 13:19) [26]

← →
Ну, я (2004-12-02 13:20) [27]

Это не я! Это сервер напулял столько. Приношу искренние извинения.

← →
msguns © (2004-12-02 13:32) [28]

>Ну, я (02.12.04 12:16) [22]
>А м.б. Вы все же обоснуете свой выбор более более аргументировано?

Если пример с восьмеркой не убедил, то других аргументов
приводить не стОит.

>А м.б. не стоит их считать ...зверями? А м.б. просто писать так, чтобы людям было удобно, а не Вам?

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

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

>Johnmen © (02.12.04 13:14) [23]
>Корректировка НД с использованием грида есть вещь нужная и крайне полезная во многих случаях (не во всех, конечно).
Давным-давно приведенный мною пример - быстрое формирование заказа со множеством позиций.

клиентский датасет, ИМХО, рулит.

← →
Ну, я (2004-12-02 13:40) [29]

msguns [28]:
М-да...
"...нажал...стрелку вниз, а при этом был выставлен NumLock и вместо перехода на след.строку ввелась цифра "8". А он не заметил и нажал другую кл., уйдя с откоррекченной записи. Прога же тупо пошлет постинг записи серверу"

Отличный аргумент ! (Типа, а мне в падлу проверять, чего он там вводит в ячейки, сам дурак). И еще: у Вас всегда "прога тупо шлет постинг в БД" ?

"клиентский датасет", говорите? А чем простой не устраивает? (Вкрадчиво: Вы же не пишете так, что все изменения в строках НД тут же передаются на сервер?)

>Ну, я (02.12.04 13:40) [29
>Типа, а мне в падлу проверять, чего он там вводит в ячейки, сам дурак

И как же ты проверишь, что новое значение, например, к-ва, которое стало = 28, на самом деле равно 2 ? В глаза юзеру посмотришь ?

>А чем простой не устраивает?
Прежде всего тем, что иногда достаточно сложно организовать изменения в БД, т.к. эти изменения могут происходить в нескольких таблицах. Кроме того, во многих случаях, в рез-те изменений срабатывют триггеры или изменения делаются ХП и бывает необходимо некоторые из них контролировать особо. Также несустраивает в случаях, когда нет быстрой сети или она работает с обрывами.
Еще в КДС я могу запихать много всяких штучек, которых нет в БД и, след-но, в датасете, получаемую запросом к БД. Эти штучки иногда очень нравятся так любимым тобою и ненавидимыми мною пользователям (раскраски записей разными цветами, всякие заморочки типа картинок, чекбоксов и прочей фигни)
При больших объемах коррекции я могу сохранить данные из КДС на компе юзера с последующей загрузкой. Это весьма удобно юзеру, например, в конце работы, когда надо бежать за ребенком в садик, а комп показывает часики, пытаясь по медленной сетке пробиться к серверу для последнего коммита. Часто в таком режиме заводятся обширные заказы, о которых упоминал тут Евгений.
Трафик при "кучных" изменениях существенно снижается.
Перевоспитывает мышление в сторону "трехзвенья", что не есть плохо.

>(Вкрадчиво: Вы же не пишете так, что все изменения в строках НД тут же передаются на сервер?)

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

>msguns © (02.12.04 13:56) [31]

Серёг, ну КДС совсем не обязателен. Можно и кешировать изменения. И также "кучно изменять".

← →
Ну, я (2004-12-02 14:16) [33]

msguns [31]:

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

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

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

- я имел в виду, что Вы же не отправляете в БД каждую строку вашего счета по мере ее введения? Вы же сначала заполняете все строки, а только потом сохраняете ваш счет целиком, нет?

PS: а пример с запавшей восьмеркой все равно не убедил... Как будто человек не может ошибиться при вводе в модальном окне.
И я просто-таки вижу ваших пользователей, к-рые при вводе многострочного документа так и скачут из одного окна в другое, вспоминая msguns"a тихим ласковым словом ;)))

>Johnmen © (02.12.04 14:13) [32]

Жень, о чем мы спорим ? Что предпочтительнее: блондинки или тушеная в красном вине телятина с трюфелями ?

>Ну, я (02.12.04 14:16) [33]
Безапелляционность и агрессивность твоих постов не позволяет мне продолжить спор. Все богатство палитры дельфей как раз и предназначено для выбора на любой вкус. Использовать же компоненты только потому, что кто-то их якобы специально для меня писал ? Флаг в руки ! Только не надо провозглашать это девизом джидаев и навязывать всем поголовно.

На сем откланиваюсь.

← →
Ну, я (2004-12-02 14:48) [35]

Попрощаюсь и я тоже. Простите меня, уважаемый msguns, если я Вас случайно чем обидел. Уж очень резанул мне глаз ваш пост номер 8, вот и не утерпел...(как-то часто мне последнее время попадаются на глаза такие утверждения...) Не огорчайтесь. В конечном итоге мы ведь пришли к общему мнению, что It depends upon when and where, правда?

PS: а все-таки, автору-то топика мы помогли? A? Как Вы относитесь к DBGrid(Eh?).Column.OnUpdate?
Почему именно так - а просто мне импонирует мысль при редактировании в db-control"ах некоторые вещи делать после того, как человек изменил данные на форме, но ДО того, как они попали в dataset - наверное, Вы из похожих побуждений отказались от db-control"ов совсем...

Johnmen © (01.12.04 23:31) [18]
Э-э-э... Не понял... Как проверяем, изменилось ли содержимое?

В событии OnColEnter присваиваем значение какой-либо переменной(например - Variant), в событии OnColExit - проверяем ее.-)

Alexander Panov © (01.12.04 22:34) [15]
Enter, редактирование, Enter, конец редактирования - остаемся в той же колонке.

Если OnValidate не устраивает, то надо переходить на уровень Inplace Editor

Понял. Извиняюсь...

Anatoly Podgoretsky © (02.12.04 22:31) [37]
Enter, редактирование, Enter, конец редактирования - остаемся в той же колонке.

Согласен.

>автору

Вот рабочий пример:

type TForm1 = class(TForm) db: TDatabase; Table1: TTable; DBGrid1: TDBGrid; DataSource1: TDataSource; Label1: TLabel; procedure FieldValidate(Sender: TField); procedure FormCreate(Sender: TObject); procedure DataSource1StateChange(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; FieldValue: Variant; implementation {$R *.dfm} procedure TForm1.FieldValidate(Sender: TField); var tf: Variant; begin tf := DBGrid1.DataSource.DataSet.FieldValues[DBGrid1.SelectedField.FullName]; if tf<>FieldValue then begin ShowMessage("!"); end; end; procedure TForm1.FormCreate(Sender: TObject); var i: Integer; begin for i := 0 to Table1.FieldCount-1 do begin Table1.Fields[i].OnValidate := FieldValidate; end; end; procedure TForm1.DataSource1StateChange(Sender: TObject); begin if DBGrid1.DataSource.DataSet.State=dsEdit then begin FieldValue := DBGrid1.DataSource.DataSet.FieldValues[DBGrid1.SelectedField.FullName]; end; end; end.

Как в DBGrid отловить окончание редактирования ячейки? Найти похожие ветки