Перехват нажатия "Применить" в TDBNavigator

← →
leonidus © (2005-09-21 09:19) [0]

Мастера подскажите как быть. Дело в том, что у меня с ADODataSet`ом связан компонент TDBNavigator, при добавлении в базу новой записи нужно предварительно по базе пройтись и проверить нет ли такой записи в базе, и если она есть то не разрешить ее добавление. В обработчике DBNavigator1BeforeAction я вызываю в этом случае метод Cancel:
ADODataSet.Cancel, при этом запись действительно не добавляется в базу, но получаю сообщение "ADODataSet: Dataset not in edit or insert mode", т.е. вроде ADODataSet не в режиме редактирования или вставки, но зачем ему находиться в этом режиме, я все равно отменяю действие? Или есть способы более элегантной отмены добавления записи?

← →
Desdechado © (2005-09-21 09:29) [1]

Мне непонятно, почему ты делаешь проверку, когда данных еще нет?
Вот сделать проверку на нажатие кнопки Post - еще понятно.
А так - правильно посылает, ибо датасет не в состоянии редактирования.

← →
Johnmen © (2005-09-21 09:43) [2]

Есть более элегантные способы.
Самый-самый из них - не применять родного криворОжденного нафигатора.

← →
ЮЮ © (2005-09-21 09:48) [3]

Потому что после выполнения DBNavigator1BeforeAction продолжается дальнейшее выполнение TDBNavigator.BtnClick(Index: TNavigateBtn), и в частности делается и попытка Post, хотя НД уже не в режиме втавки.
Поэтому в DBNavigator1BeforeAction после Cancel следует сделать Abort, что должно прервать и дальнейшее выполнеие метода BtnClick

← →
leonidus © (2005-09-21 09:53) [4]

>Desdechado ну почему же данных еще нет. Есть таблица, и есть набор TDBEdit`ов, а также TDBNavigator, все они привязаны к одному ADODataSet`у. В навигаторе жмем "+", TDBNavigator переводит ADODataSet в режим Edit мы начинаем в TDBEdit`ы вводить данные новой записи. Когда все ввели в TDBNavigator жмем "Применить" и попадаем в обработчик DBNavigator1BeforeAction где нужно пройтись по таблице (я использую Lookup: LookupResult:=ADODataSet1.Lookup("inv nomer",inv_nomer,"inv nomer") ) и если в таблице существует запись в поле "inv nomer" которой уже существует указанное только что в TDBEdit значение, то нужно вызвать метод Cancel, что бы эта запись не попала в таблицу и не создала в ней две записи с одинаковым значением поля inv nomer. Так что же я делаю не так?

← →
leonidus © (2005-09-21 09:55) [5]

>ЮЮ
у TADODataSet нет метода Abort....

← →
ЮЮ © (2005-09-21 09:56) [6]

это не метод. Это как exit, только круче :)

← →
Sergey13 © (2005-09-21 10:02) [7]

2 [4] leonidus © (21.09.05 09:53)
Когда ты вызываешь Lookup по редактируемому набору происходит переход на другую запись и соответственно вызывается Post. Далее при Cancel ты получаешь то, что и должен получить.
Проще, ИМХО, добавить (если нет еще) уникальный индекс на "inv nomer" и ловить исключение.

← →
Anatoly Podgoretsky © (2005-09-21 10:09) [8]

Сколько вреда принес этот нафигатор начинающим программистам и как мало пользы он принес пользователям.

← →
leonidus © (2005-09-21 10:14) [9]

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

← →
Sergey13 © (2005-09-21 10:19) [10]

2 [9] leonidus © (21.09.05 10:14)
А дебагером пройтись не пробовал для поика места возникновения исключения?

← →
leonidus © (2005-09-21 11:14) [11]

Пришлось отказаться от TDBNavigator

← →
Плохиш © (2005-09-21 11:40) [12]

> leonidus © (21.09.05 09:19)

Правильное место для проверки записываемых данных TADODataSet.OnBeforePost, а правильная процедура для отмены сохранения Abort.

PS. Справка - рулез форева!

← →
msguns © (2005-09-21 14:39) [13]

>leonidus © (21.09.05 11:14) [11]
>Пришлось отказаться от TDBNavigator

Следующая ступень - отказ от редактирования в гриде.

← →
Sergey13 © (2005-09-21 14:43) [14]

2 [13] msguns © (21.09.05 14:39)
Не отдадим святого! Ни щагу назад!

← →
msguns © (2005-09-21 14:52) [15]

>Sergey13 © (21.09.05 14:43) [14]

Опять кулачки зачесались, Серега ?
А я сегодня пушисто-добродушный, поэтому типа пас ;)

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

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

2[18] ANB © (21.09.05 14:55)
А я пишу как удобнее и правильнее с точки зрения задачи (и с моей точки зрения разумеется 8-). Иногда так иногда эдак.

>ANB © (21.09.05 14:55) [18]
>- а для себя я завсегда пишу программы, где редактирование в гриде. А добавление - в отдельной форме.

Универсального правила быть не может. Все зависит от сорта данных, доступа к ним, внутренней структуры. А также от особенностей клиента, "под которого" разрабатывается интерфейс.

Категорически возражаю против редактирования в гриде данных, которые должны тотчас же отправляться на сервер дабы их наблюдали все остальные(т.е.публиковаться). Например, накладных в задачах, непредусматривающих понятие "отложенный/откаченный документ". Мало того, что "неявный" (т.е. юзер вроде ничего не сделал - только нажал кнопку "вниз") тормоз, так еще и велика вероятность непредумышленной коррекции (нажат нумлок, а юзер хотел перейти к след.записи с помощью кл "2", в рез-те чего цена стала не 0,2, а 0,22), для избежания последствий которых приходится писать массу ненужных обработчиков типа BeforePost.
В то же время таблиці-сетки (как пример-табель учета рабочего времени) очень удобно редактировать именно в гриде. Однако в таких случаях я использую объекты, не связанные напрямую с таблицей БД, например, стрингрид или CDS. В таком приложении коррекция делается за раз по кнопке.

← →
Ukrainian (2005-09-21 18:31) [21]

> В то же время таблиці-сетки

Ukraine-forever

Перехват нажатия "Применить" в TDBNavigator Найти похожие ветки