Они хоть чего нибудь сделали в этой либе!? Значения по умолчанию нельзя. Где спрашивать подтверждение удаления -- тоже непонятно. Предусмотрено в DataGridView, но это неподходящее место, так как я могу удалять не только там, но и из навигатора какого-нибудь...

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

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

Вот например, существует же ОДНО событие FormClosing. И неважно, как ты закроешь форму -- крестиком, кнопкой, Alt-F4 или двухкратным кликом на иконке -- всё равно это событие вызовется и там можно будет спросить подтверждения. 

А с удалением записи будет куча мест. Причём даже нельзя будет написать одну функцию и отовсюду её вызывать. Потому что метод обработки подтверждения везде разный: при обработке UserDeletingRow в гриде надо поставить e.Cancel=true, а при обработке кнопки навигатора нужно будет эту кнопку перевести в режим none, а потом самому, если надо, отдать команду удаления!

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

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

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

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

Добавлено через 2 минуты и 23 секунды

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

Dims, вот тебе задача: есть одна форма, которая отображает данные из таблицы Тееу1 в режиме ридонли. Есть еще одна форма, которая отображает данные из той же таблицы (не важно по какой причине требуется две такие формы). Вопрос, где разместить код запроса одних и тех же данных из одной и той же таблицы так, чтобы можно было легко поддерживать код?

Ну так посоветуй. 

Рассмотрим простейщий пример. В базе ОДНА таблица. 



Ничего ведь сложного, банальность, правда?

Я делаю на форме DataGridView и BindingNavigator, всё подсоединяю -- и сразу не работает. Почему? Потому что не понимает значения по умолчанию для поля Added.

Ладно, хрен с ним, делаем вручную. Приходится делать это сразу в двух местах:



Обрати внимание, какой кретинский код! Лучше я не смог придумать! Может, ты подскажешь? Смотри, как через задницу определяется местоположение поля, которому требуется значение по умолчанию: сперва происходит обращение к объекту колонки, который был создан мастером, определяется его индекс, а потом по этому индексу ищется поле среди клеток. Я не нашёл способа адресовать колонку по имени НИГДЕ. Подскажи, плиз, если знаешь.

Теперь второй метод. Он делает то же самое, но совершенно через другую задницу. Записать это в виде одной функции не представляется возможным. Обрати внимание, что если у DataGridView происходит вмешательство в существующий процесс, то у BindingNavigator-а совершенно другая идеология: у него штатную функцию приходится отключать в визуальном дизайнере и полностью выполнять операцию самостоятельно. 

Такое впечатление, что автор одного элемента управления не имел никакого представления о другом или даже ненавидел его. Соответственно, автор второго элемента отвечал ему взаимностью.

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



Здесь каждый метод сам по себе не особо плох. Но они ведь совершенно разные! Даже ответ в первом случае сравнивается на "Нет", а во втором -- на "Да". И снова во втором случае ещё надо в визуальном дизайнере отключать функцию.

Кстати, нафига тогда нужен этот BindingNavigator, если я у него всё равно все функции вынужден отключать и он превращается просто в кучу кнопок, которые я могу нарисовать и без него?

Вот подскажи мне, как пример выше можно сделать по-нормальному.

Это сообщение отредактировал(а) Dims - 17.2.2011, 22:29

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

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

Я не знаю. В настоящее время у меня впечатление, что лучше вообще не пользоваться микрософтовскими полоумными наработками для работы с СУБД, а найти какую-нибудь стороннюю либу или написать свою. Чтобы всё было осмысленно. 

Но если уж надо, то, думаю, что нужно где-то вручную создать статический BindingSource и вручную же прописать его всем гридам.

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

Ну так ты, как профессионал, подтверждаешь, что это всё ерунда?


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


Сокеты принципиально отличаются от навигатора тем, что они МОГУТ быть нужны. А навигатор -- это порождение полоумного программиста, которое не может быть нужно никогда. Так же как, видимо, весь остальной мусор с датасетами, биндерами, адаптерами и прочей шелухой.

Просто я-то не знал, что вот эта вся гора -- это гора мусора. А ты сразу не сказал, мол, что это ошибка, юзать этот фреймворк.

угу, а еще можно написать свой язык и не парится о том что этот такой "кривой"!!!

а лучше взять учебник и почитать, про язык, про программирование под WinForms, про ADO.NET, про привязку данных, etc. а потом на верх про паттерны и ООП в принципе и тогда все будет отлично сходится и не будут появляться такое негодование и подобные вопросы.

Добавлено через 3 минуты и 54 секунды

при чем тут фреймворк?
повторюсь у тебя все упирается в организацию тобой твоего кода. для примера SQL запрос начинающийся со слова DELETE тоже удаляет записи, и при этом ничего не спрашивает


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

Добавлено через 9 минут и 15 секунд
кстати, а про DataSet ты читал? ну хотя бы ради интереса? он может существенно помочь во всех этих вопросах, если конечно с ним разобраться как следует...

Естественно, если никто не подскажет, я во всём сам разберусь...

"Свой язык" -- это постоянно преследующая меня мысль 

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

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

Ещё раз. Ты почему-то стесняешься напрямую назвать штатные средства Visual Studio "ненормальными". Так ты назови, мне будет понятнее. Я же ничего не изобретаю, а делаю ровно то, что мне говорит Студия. Смотри. Я хочу написать программу с базой. Имею право? Имею. Делаю "создать базу". Никакой крамолы. Дальше она САМА создаёт датасет, САМА мне говорит, что база ПОКА пуста. Мол, ты иди, сперва создай в базе объекты, а потом ПЕРЕТАСКИВАЙ их на датасет. Это не я придумал! Я сделал базу и перетащил. В чём проблема? Далее. DataGridView. Ты почитай, что про неё пишут -- крутой контрол, который супер-пупер кастомизируем, позволяет работать с миллионами записей и так далее. Просто положи на форму и укажи датасорс. Ну я так и делаю. Она при этом САМА создаёт биндингсорс и через него подключается к соответствующием дататейблу.

На так что, это всё ненормально? 

Я так думаю, ты нифига не прочёл моих вопросов, раз пишешь, что у меня датагрид "напрямую работает с базой". Или, может, ты никогда не создавал в проекте XSD файлы и тебе просто непонятно, о чём у меня речь?

У меня вполне конкретные вопросы по этим объектам. А философствовать про разделение концернов я и сам могу.

Это сообщение отредактировал(а) Dims - 17.2.2011, 23:38

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

Добавлено через 48 секунд
а необходимость проверки это должно быть твое решение, а не навигатора.

А я разве говорил, что его надо вставлять в навигатор? Это ответ от эксперта на микрософтовском форуме. Вот ссылка http://social.msdn.microsoft.com/Forums/en...5-9bf15016857f/
Человек спросил, как перехватить удаление -- ему ответили. Если бы можно было перехватить в лучшем месте, наверное, ответили бы про него. А раз ответили так, значит это единственный способ.

Я не понял, ты знаешь лучше что ли? Так что же не говоришь?


Я с тобой полностью согласен. 

Вот и покажи мне на примере выше, куда его можно поместить. Для примера предположи, что у нас есть ОДНОВРЕМЕННО и навигатор и грид.

Это вопрос этой темы и нифига он так и не отвечен. Поройся в на микрософтовском форуме. Когда спрашивают про грид, там отвечают, что надо перехватывать UserDeletingRow, а когда про навигатор -- то выключать кнопку и писать свой код. Никакого ОДНОГО МЕСТА, о котором ты толкуешь, и которое, я с тобой полностью согласен, ДОЛЖНО быть, НЕТ.

Если знаешь -- скажи. Пример выше есть, он очень простой.

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

и вот что я обнаружил. в моем примере ВСЕГДА сначала обрабатывается событие dataGridView1_RowsRemoved, а потом уже событие нажатия на кнопку(если таковое было вообще). а значит если я помещу код проверки в событие dataGridView1_RowsRemoved то это и будет одно место которое обрабатывает в любом случае(потому что строка из грида удаляется в обоих случаях!). или у тебя как то по другому?

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


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

на мой взгляд это доказывает тот факт что всегда есть ОДНО место в котором все сходится.

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

Dims, ты уже довел бедного человека до крайностей   
То что предлагает студия, называются средства быстрого развертывания, и полезны они, только для очень простых приложений. Студия тебе не говорит что дальше делать, как ты сказал. Она тебе предлагает создать некоторый код за тебя по фиксированному, заложенному программистами студии шаблону. А дальше, уже ты должен принять решение, устраивает ли тебя этот шаблон или нет. Вот как в твоей программе ты спрашиваешь, удалить эту запись или нет. И по большому счету, тебе по барабану, что выберет пользователь, ты даешь ему выбор, различные варианты, предупреждения, и пишешь код для всех возможных вариантов выбора пользователя. Ответственность, всегда лежит на пользователе. Вот если ты сам, без ведома пользователя удалишь запись, вот тут косяк, у пользователя не было другого выбора. Надеюсь ты понимаешь о чем я. Экскалупатор тебе дает правильные советы. Начни с изучения архитектурных вопросов, это реально поможет. Введи в свое приложение как минимум еще один слой и большинство вопросов отпадут сами собой. Потом появятся другие вопросы, еще, и еще... Например как уведомить всех сетевых клиентов, подключенных к базе, о том что запись удалена, для того чтоб они автоматически обновили свои гриды. а потом еще как запретить удаление записи, если на другом клиенте ее редактируют. В конце концов, ты прийдешь к одному решению, в котором у тебя будет многослойная и многоуровневая архитектура, в которой будет DAL, DALL и BLL и прочие слои.  И, к твоему удивелнию, архитектура будет настолько простой и понятной тебе, что ты будешь с печалью вспоминать вот эти дни. 
Почему никто конкретно еще не сказал тебе ответ вот тыкни здесь и все будет в порядке? Потому что в конкретном твоем случаю нужно выеживаться как фиг его знает кто, чтоб решить вопрос. Почему так? Потому что выбран не верный путь для твоей задачи. Экскалупатор уже сказал, что тебе нужен рефакторинг, то есть пересмотр архитектурного вопроса. чтобы тебе щас помочь тут в твоем вопросе, и сказать как надо сделать, нужно тут переписать изрядное количество уже написанных на эту тему статей.

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

PPS: Я занимаюсь разработкой на .NET уже 9 лет, а до этого еще несколько лет на других языках и платформах. Начинал вообще с ZX-Spectrum с тактовой частотой 3.5МГц. И я понимаю тебя, потому что проходил этот путь. Могу заявить однозначно, что для быстрой разработки бизнес-приложений под винду, платформа .NET является самым лучшим выбором из того, что я знаю. Не нужен тебе свой язык программирования, потому что в итоге, у тебя получится C#   

Я так тоже подумал, но Экскалупатор стал прикалываться, мол, ты ещё свой язык напиши. То есть, остаётся непонятным, применять эти средства и выкручиваться, или не применять совсем и идти другим путём?


Так какой верный? Вот есть база с одной простой таблицей. Мне нужен простой редактор этой таблицы. Как поступать "верно"? Что использовать, а что не использовать? В двух словах опиши плиз.


Слои -- это хорошо. Но в этих слоях же будет где-то расположен код, который спрашивает подтверждение удаления записи? Вот у меня и вопрос: где? Я так понимаю, ты хочешь сказать, что он НЕ ДОЛЖЕН находиться в обработчике UserDeletingRow датагрида? Так? Если так, то что с датагридом? Он же удаляет запись сам. Если в его работу не вмешаться, запись будет удалена. Его что, надо отсоединить от датасорса? Использовать в unbound режиме и самому копировать данные в базу? Так?


Разве у меня в примере выше однослойное приложение? Хотя и средствами быстрого развёртывания, но у меня же создаётся ДатаСет, Адаптеры, которые копируют данные, БиндингСорсы, Контролы. Разве это не слои?

Добавлено через 2 минуты и 11 секунд

Как раз волнует. Ты зачем-то стал делать не так, как сам считаешь правильным. А меня интересует именно как правильно.

Попробовал такой метод.


Добавляю обработчик события к DataTable



а в нём


Работает плохо: запись возвращается при отмене, но перестаёт быть текущей.

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

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

по поводу изменения сгенерированного кода, то что его не принято изменять это мнение некоторых программистов. я нигде это не читал, и просто высказал одну из точек зрения. все что НЕЛЬЗЯ изменить студия блокирует и вмешаться туда не возможно. а в эти коды вполне возможно и ты можешь их переписать как тебе удобно. никто не мешает.

если ты значешь что это за строка(номер ее в коллекции грида) то почему нельзя сделать ее обратно текущей?

Объясни своё видение: как должно быть? Грид должен быть в unbound режиме? И самому копировать данные туда-сюда?

ну в общем да, я приверженец такого подхода. просто когда то писал приложение через мастер и меня очень удивил дата сет в 2 к строк. который работал секунд на 5 дольше чем тот же функционал написанный мной лично. с тех пор я не люблю автоматически сгенерированные штуки(но это личное). касательно к проблеме. я бы сделал класс для работы с базой, класс формы и что то на подобии бизнеслогики. форма сообщает бизнеслогике что ей что то нужно(заполнить грид), логика дергает класс базы, получает результат - кидает на форму. если ты хочешь что то удалить, то ты берешь номер строки из грида(я обычно грид использую только для отображения, а все данные храняться в дататейбле и туда обычно запихиваю столбец ID, с номерами из базы, что бы можно было найти конкретную строку в базе). короче при удалении берем запрос вставляем туда ID и кидаем его в класс работы с базой, он удаляет. дата грид обновляем. вопрос пользователю задаем из бизнеслогики перед выполнением кода работы с базой. в результате все приложение это строчек 100-150(имею в виду те что придется написать самому), при этом все что работает с базой собрано в одном месте, и при удалении из грида или нажатии на крестик в навигаторе будет вызываться один и тот же код в бизнеслеере в котором можно написать любые проверки которые сочтешь нужным. ну как то так, в общих чертах.

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

Не понял, зачем/как ты применяешь дататейбл, если грид у тебя unbound, а  с базой ты работаешь при помощи запросов? 

Иными словами, у тебя в свойстве DataSource у грида что-нибудь указано? Там указан дататейбл или там пусто?

Это сообщение отредактировал(а) Dims - 18.2.2011, 13:22

в DataSource указана таблица из датасета(или просто таблица). а вот таблицу я получаю отдельно, выполняя запрос на выборку данных из базы.

Если в DataSource указана таблица, то как ты можешь помешать гриду удалить оттуда запись?

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

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

Блин, на колу мочало, начинаем всё сначала!

Задание такое: НАДО чтобы удалять было МОЖНО, но при этом СПРОСЯСЬ у пользователя.

Пользователь даёт команду удаления записи и В ЭТОТ момент его надо спросить. Не потом, через час, когда он забудет, о чём речь, а именно в момент, когда он даёт команду.

Поэтому нафига ты мне рассказывашь, что запись не удаляется, а только помечается? Какая разница? Всё равно она будет удалена. СПРАШИВАТЬ потом будет бессмысленно: "дорогой пользователь, 15 минут назад вы пометили для удаления запись такую-то там-то и там-то, вы действительно сделали это осознанно"? Абсурд!

А если он 150 записей за это время удалит? Его что, кучей вопросов бомбардировать?

да блин, я не понимаю в чем проблема! у тебя есть грид, пользователь жмет кнопку, по умолчанию грид ничего сам не делает, ты пишешь обработчик события нажатия кнопки и в нем спрашиваешь у пользователя все что нужно. естественно что пользователя волновать не должно как дальше удаляется запись, и спрашивать надо в момент нажатия кнопки, все верно. про то что она сразу не удаляется я просто к тому что бы ты был в курсе того что происходит. все равно вся работа по удалению происходит через слой бизнеслогики(должна происходить). ты пойми, что в описанной мной ситуации грид сам ничего не решает, он существует только что бы отобразить данные из таблицы(из DataTable а не из базы данных напрямую), и для того что бы отреагировать на действия пользователя и понять что он хочет сделать(удалить или еще чего), но сам процесс(удаления, добавления и пр.) делается НЕ ЧЕРЕЗ ГРИД. грид просто генерирует событие что пользователь ХОЧЕТ что то сделать, а ты уже в написанном ТОБОЙ коде решаешь что и как будет происходить дальше(спрашивать что то еще. или просто делать без вопросов).

Добавлено через 1 минуту и 54 секунды
я тебе предлагал запускать процесс удаления сразу после того как пользователь нажал на кнопку(я так и написал выше). т.е. пользователь нажал "удалить", ты у него спросил "точно?", пользователь нажал "Да!", ты запустил выполнение запроса на удаление записи.

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

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


Как это можно обеспечить? У тебя грид подключён к таблице. Значит, чтобы грид не удалял записи, эту операцию надо в нём выключить. В этом случае грид ничего никому сообщать об удалении записей не станет. Так? Или ты имеешь в вижу события нажатия клавиатурных клавиш?

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


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

в общем я смотрю это все сильно затягивается пора заканчивать. у тебя есть три пути:
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 и еще все остальную кучу...