![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как в DBGrid отловить окончание редактирования ячейки?
IceBeerg © (2004-12-01 18:14:00)собсвенно сабж
Alexander Panov (2004-12-03 20:07:00) [1]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.
SergP (2004-12-03 06:17:00) [2]Понял. Извиняюсь...
SergP (2004-12-03 06:15:00) [3]2 Anatoly Podgoretsky ©
А что такое OnValidate ?
Что-то не вижу я такого события ни у грида, ни у датасета...
Anatoly Podgoretsky (2004-12-02 22:31:00) [4]Alexander Panov © (01.12.04 22:34) [15]
Enter, редактирование, Enter, конец редактирования - остаемся в той же колонке.
Если OnValidate не устраивает, то надо переходить на уровень Inplace Editor
Alexander Panov (2004-12-02 22:21:00) [5]Johnmen © (01.12.04 23:31) [18]
Э-э-э... Не понял... Как проверяем, изменилось ли содержимое?
В событии OnColEnter присваиваем значение какой-либо переменной(например - Variant), в событии OnColExit - проверяем ее.-)
Ну, я (2004-12-02 14:48:00) [6]Попрощаюсь и я тоже. Простите меня, уважаемый msguns, если я Вас случайно чем обидел. Уж очень резанул мне глаз ваш пост номер 8, вот и не утерпел...(как-то часто мне последнее время попадаются на глаза такие утверждения...) Не огорчайтесь. В конечном итоге мы ведь пришли к общему мнению, что It depends upon when and where, правда?
PS: а все-таки, автору-то топика мы помогли? A? Как Вы относитесь к DBGrid(Eh?).Column.OnUpdate?
Почему именно так - а просто мне импонирует мысль при редактировании в db-control'ах некоторые вещи делать после того, как человек изменил данные на форме, но ДО того, как они попали в dataset - наверное, Вы из похожих побуждений отказались от db-control'ов совсем...
msguns (2004-12-02 14:29:00) [7]>Johnmen © (02.12.04 14:13) [32]
Жень, о чем мы спорим ? Что предпочтительнее: блондинки или тушеная в красном вине телятина с трюфелями ?
>Ну, я (02.12.04 14:16) [33]
Безапелляционность и агрессивность твоих постов не позволяет мне продолжить спор. Все богатство палитры дельфей как раз и предназначено для выбора на любой вкус. Использовать же компоненты только потому, что кто-то их якобы специально для меня писал ? Флаг в руки ! Только не надо провозглашать это девизом джидаев и навязывать всем поголовно.
На сем откланиваюсь.
Ну, я (2004-12-02 14:16:00) [8]msguns [31]:
Ну что-ж... Приходится признать, что мы не поняли друг друга...
И все же, для тех, кто м.б. будет это читать, чтобы определиться:
используйте Грид там, где это возможно! Не бойтесь и не слушайте таких фанатов. Вы сами поймете, где лучше применить др. метод (безусловно, такие особые ситуации есть, но они не отвергают саму возможность делать так, как проще и удобнее в общем случае).
И, конечно, мспользуйте DB-control'ы. Не будьте мазохистами. Их специально сделали для вас.
"пишу, и очень даже часто. Например в сетевых торговых приложениях, где выписанный по счету товар тут же должен попадать в резерв, чтобы не быть выписанным вторично"
- я имел в виду, что Вы же не отправляете в БД каждую строку вашего счета по мере ее введения? Вы же сначала заполняете все строки, а только потом сохраняете ваш счет целиком, нет?
PS: а пример с запавшей восьмеркой все равно не убедил... Как будто человек не может ошибиться при вводе в модальном окне.
И я просто-таки вижу ваших пользователей, к-рые при вводе многострочного документа так и скачут из одного окна в другое, вспоминая msguns'a тихим ласковым словом ;)))
Johnmen (2004-12-02 14:13:00) [9]>msguns © (02.12.04 13:56) [31]
Серёг, ну КДС совсем не обязателен. Можно и кешировать изменения. И также "кучно изменять".
msguns (2004-12-02 13:56:00) [10]>Ну, я (02.12.04 13:40) [29
>Типа, а мне в падлу проверять, чего он там вводит в ячейки, сам дурак
И как же ты проверишь, что новое значение, например, к-ва, которое стало = 28, на самом деле равно 2 ? В глаза юзеру посмотришь ?
>А чем простой не устраивает?
Прежде всего тем, что иногда достаточно сложно организовать изменения в БД, т.к. эти изменения могут происходить в нескольких таблицах. Кроме того, во многих случаях, в рез-те изменений срабатывют триггеры или изменения делаются ХП и бывает необходимо некоторые из них контролировать особо. Также несустраивает в случаях, когда нет быстрой сети или она работает с обрывами.
Еще в КДС я могу запихать много всяких штучек, которых нет в БД и, след-но, в датасете, получаемую запросом к БД. Эти штучки иногда очень нравятся так любимым тобою и ненавидимыми мною пользователям (раскраски записей разными цветами, всякие заморочки типа картинок, чекбоксов и прочей фигни)
При больших объемах коррекции я могу сохранить данные из КДС на компе юзера с последующей загрузкой. Это весьма удобно юзеру, например, в конце работы, когда надо бежать за ребенком в садик, а комп показывает часики, пытаясь по медленной сетке пробиться к серверу для последнего коммита. Часто в таком режиме заводятся обширные заказы, о которых упоминал тут Евгений.
Трафик при "кучных" изменениях существенно снижается.
Перевоспитывает мышление в сторону "трехзвенья", что не есть плохо.
>(Вкрадчиво: Вы же не пишете так, что все изменения в строках НД тут же передаются на сервер?)
Громогласно: бывает, что пишу, и очень даже часто. Например в сетевых торговых приложениях, где выписанный по счету товар тут же должен попадать в резерв, чтобы не быть выписанным вторично.
Johnmen (2004-12-02 13:44:00) [11]>msguns © (02.12.04 13:32) [28]
>клиентский датасет, ИМХО, рулит.
Наверное, рулит...
А причем он здесь ?
:)
Ну, я (2004-12-02 13:40:00) [12]msguns [28]:
М-да...
"...нажал...стрелку вниз, а при этом был выставлен NumLock и вместо перехода на след.строку ввелась цифра "8". А он не заметил и нажал другую кл., уйдя с откоррекченной записи. Прога же тупо пошлет постинг записи серверу"
Отличный аргумент ! (Типа, а мне в падлу проверять, чего он там вводит в ячейки, сам дурак). И еще: у Вас всегда "прога тупо шлет постинг в БД" ?
"клиентский датасет", говорите? А чем простой не устраивает? (Вкрадчиво: Вы же не пишете так, что все изменения в строках НД тут же передаются на сервер?)
msguns (2004-12-02 13:32:00) [13]>Ну, я (02.12.04 12:16) [22]
>А м.б. Вы все же обоснуете свой выбор более более аргументировано?
Если пример с восьмеркой не убедил, то других аргументов
приводить не стОит.
>А м.б. не стоит их считать ...зверями? А м.б. просто писать так, чтобы людям было удобно, а не Вам?
А м.б. надо писать так, чтобы в целом система работала надежно и быстро ? Представь, что в армии под каждого Ваню оружейники будут модернизировать конструкцию приклада автомата.
Впрочем, в этом вопросе не может быть однозначного решения. В каждом конкретном случае принимаются свои решения.
По сабжу ничего не известно об этом самом случае. Просто по опыту знаю, что чаще всего редактирование в гриде есть не следствие необходимости, но инерции мышления разработчика или "каприз" пользователя (не встречал еще ни одного пользователя, обидевшегося на кличку "юзверь", включая директоров и президентов компаний)
>Johnmen © (02.12.04 13:14) [23]
>Корректировка НД с использованием грида есть вещь нужная и крайне полезная во многих случаях (не во всех, конечно).
Давным-давно приведенный мною пример - быстрое формирование заказа со множеством позиций.
клиентский датасет, ИМХО, рулит.
Ну, я (2004-12-02 13:20:00) [14]Это не я! Это сервер напулял столько. Приношу искренние извинения.
Ну, я (2004-12-02 13:19:00) [15]Отрадно слышать, что не все такие упертые как msguns...
Я даже думаю, что их меньшинство!
PS: ну а пл теме топика - закрыта?
Ну, я (2004-12-02 13:17:00) [16]Отрадно слышать, что не все такие упертые как msguns...
Я даже думаю, что их меньшинство!
PS: ну а пл теме топика - закрыта?
Ну, я (2004-12-02 13:17:00) [17]Отрадно слышать, что не все такие упертые как msguns...
Я даже думаю, что их меньшинство!
PS: ну а пл теме топика - закрыта?
Johnmen (2004-12-02 13:14:00) [18]Корректировка НД с использованием грида есть вещь нужная и крайне полезная во многих случаях (не во всех, конечно).
Давным-давно приведенный мною пример - быстрое формирование заказа со множеством позиций.
Ну, я (2004-12-02 12:16:00) [19]msguns [21]:
А м.б. Вы все же обоснуете свой выбор более более аргументировано?
>>идеология организации данных в екселе и SQL серверах несколько отличается ;)
Кто-то утверждал обратное?
>>Помучившись с юзверями..
А м.б. не стоит их считать ...зверями? А м.б. просто писать так, чтобы людям было удобно, а не Вам?
Конечно, голова у программера болит меньше, когда он себе облегчает жизнь и заставляет всех остальных редактировать данные в модальных формах с не-DB control-ами?
В общем, пока доводов не увидел...
msguns (2004-12-02 11:58:00) [20]>IceBeerg © (01.12.04 19:00) [11]
>>2. Выбросить на свалку привычку давать редактить в гриде и перейти к модальным формам
>Возможно этим и кончиться, но тем юзверям кому я это пишу можно давать возможность редактировать непосредственно DBGrid, так производительность будет выше.
Ты имеешь в виду редактирование колонки ? Типа в прайс-листе, когда юзверь корректит только одну колонку (цены), перемещаясь стрелками вверх-вниз ?
В этом случае, ИМХО, лучше работать через TClientDataSet, периодически сбрасывая изменения порциями. Так действительно будет шустрее и удобнее. Если же простое редактирование строк (типа как в фактуре накладной), то никакого повышения производительности от "гридного" редактирования не вижу, т.к. юзверь за один момент не может править более одной записи. Зато вот вероятность "проскакивания" фантомных изменений (это когда юзверь, например, нажал на кейпаде стрелку вниз, а при этом был выставлен NumLock и вместо перехода на след.строку ввелась цифра "8". А он не заметил и нажал другую кл., уйдя с откоррекченной записи. Прога же тупо пошлет постинг записи серверу.
>Ну, я (02.12.04 11:32) [20]
>Господи, и здесь такие же маньяки, как на SQL.RU Да откуда вы беретесь такие???
Из жизни, милейший. Помучившись с юзверями, привыкшими в "эксельной" технологии правки данных. Просто идеология организации данных в екселе и SQL серверах несколько отличается ;)
Зато когда юзверя переучил (переубедил), он существенно ответственнее отностися к своей работе вообще и к каждой операции (под операцией понимается манипуляции над объектом БД в целом, а не над какими-то его частями). Как следствие, резкое сеижение конфликтов и потерь данных и рост скорости и надежности работы всей системы.