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


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

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

я за вариант №3. для этого тебе нужно почитать книжечек пару штук, и разобраться как это работает, ты сильно выиграешь в этом случае(по крайней мере разберешься как это работает) и сделаешь так как тебе хочется, с любыми проверками и так как тебе удобно, писать не много(знаю по опыту), за минут 20-30 не торопясь, можно набросать рабочую версию. ну и минут за 20 - 30 довести ее до ума(если все так как ты описал), итого час работы. а мы уже тут второй день трепемся. не нравятся встроенные? не пользуйся, никто не заставляет, но других нету...

Добавлено @ 15:50

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

Это сообщение отредактировал(а) Экскалупатор - 18.2.2011, 15:50

А по мне так надо делать нечто вроде (тут описано не "панацея")
Configuration - класс (обычно статический) дающий в приложение конфигурацию
Data - слой абстракции к данным. Например NHibernate или EF или хоть ADO.NET. Тут просто работа с данными, без логики
Repository - слой доступа к данным, см. паттерн репозиторий
Win.Controllers - слой контроллера для WinForms приложения. Контроллеры это реакция на действия, а также получение конкретных данных (Ienumerable например) для маппинга их на слое View
Win.View - просмотр данных, работа в OnClick-ах сводится к вызову метода из контроллера. Тут же всякий визуально-завимисимый код (типа "линию сделать красной в гриде").
Application - микроприложение, собственно запускющее всю эту кухню в действие.

Конечно, связь везде через интерфейсы. Конкретные классы привязываются через Unity (например). Сами контроллеры  и View затягиваются в приложение через MEF (например)...

...реакция на события "Уверены что сохранить?" возможна в контроллере (не очень кошерно), а лучше в View как реакция на callback из контроллера (например подпиской на события аналогично методу Closing, где можно "отменить продолжение операции" поставив соотв. флаг в EventArgs).

......

Это сообщение отредактировал(а) jonie - 18.2.2011, 21:39

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

Тут вопрос в другом был... Ничего, со временем Dims'у станет все понятно. Это определенный процесс, все через него прошли рано или поздно.

Потому что Грид не будет вызывать эту процедуру сам собой. У грида есть определённый функционал, частью которого является возможность удалять записи. Прямо из грида. Чтобы воспользоваться хранимой процедурой, либо каким-то другим способом централизации процесса удаления, нужно будет этот функционал отключить.

Добавлено через 6 минут и 58 секунд

Да, думаю, переопределить этот метод -- оптимальное решение. Инфраструктура как раз для этого приспособлена: если ткнуть два раза в изображение таблицы в дизайнере, то попадаещь в редактор partial класса DataTable -- там и можно это сделать. Думаю, там нужно добавить запуск события наподобие как в гриде, с возможностью отмены -- и обрабатывать его в слое отображения.

Добавлено через 13 минут и 25 секунд
Хотя нет, этот метод уже определён, а это значит, придётся вмешиваться в код визарда. Некузяво.

Да и вообще. Подозреваю, что с OnRowDeleting и не получилось бы. Нигде не сказано, что base.OnRowDeleting собственно удаляет запись. Скорее всего, он выполняет связанные с этим операции, например, каскадное удаление. Так что блокировка этого вызова в переопределённом методе ничего бы не дала.

В общем, такое впечатление, что неверно спроектирован компонент BindingSource. Именно он должен был бы, как мне кажется, отвечать за эту функцию. У него есть методы Remove, RemoveAt и RemoveCurrent. Скорее всего, именно их вызывает грид и другие привязанные компоненты. В свою очередь, эти методы, наверняка транслируют удаление ниже, на слой работы с данными, в DataTable. То есть, именно в этом компоненте и должно было быть размещено событие для проверки удаления. Так же, именно тут должен был быть расположен функционал по заданию значений по умолчанию клиентского уровня...

Наследуйтесь от своего типизированного DataTable и перекройте этот метод... не забудьте вызвать base.OnRowDeleting в нужном месте.


Также, рассмотрите возможность наследования от него.

PS: Я еще раз, настоятельно рекомендую, хотя бы начать рассматривать возможности и принципы WPF. Не для этого случая, а вообще. Чем раньше, тем лучше.

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

Добавлено через 1 минуту и 5 секунд

Имеется в виду Windows Presentation Foundation? Его я тоже изучаю, но не знал, что они там с базами тоже что-то наворотили.

Они там не с базами натворили, а с источниками данных и привязкой UI к ним. В качестве источника данных, по-прежнему может выступать любой объект, а вот привязка выглядит теперь оригинально. Лично я очень люблю все эти фишки с DataContext, Biniding, Template, DataTemplate, Style, Resources, RoutedEvents, RoutedCommands и еще все остальную кучу...