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


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

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

Это сообщение отредактировал(а) Экскалупатор - 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 секунды
я тебе предлагал запускать процесс удаления сразу после того как пользователь нажал на кнопку(я так и написал выше). т.е. пользователь нажал "удалить", ты у него спросил "точно?", пользователь нажал "Да!", ты запустил выполнение запроса на удаление записи.

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

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


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