Proper way to handle deletes in a DataGridView?

Proper way to handle deletes in a DataGridView?

Old forum URL: forums.lhotka.net/forums/t/2487.aspx

frankhoffy posted on Wednesday, March 07, 2007

I'm the only person in my organization who has implemented a fully updateable DataGridView using CSLA, so I'm looking for some advice from you folks.

The DataGridView works great on inserts and updates.  If there is a broken business rule, the user sees the nice little error provider icon showing them that something is wrong.

My question is, what if something goes wrong on a delete?  The row has been removed from the grid, and it has been removed from the underlying collection.  There's no way to show them the little exclamation point that something is wrong.

The UserDeletingRow event won't work, because changes haven't been written back to the list at that point.

Any ideas would be appreciated.

ajj3085 replied on Thursday, March 08, 2007

What would go wrong on a delete?  Do you mean the actual delete command running, or simply being marked as deleted?  Or by deleting the object, have you broken a business rule?

bearntrail replied on Wednesday, June 27, 2007

I'm having the same issue.  In my case, the delete fails because another user has updated the record and my stored procedure aborts the delete, returning an error. 

To get around the DataGridView issue, I implemented an UnDelete(child) in the Business class and call it when the Save fails.  I also question whether this is the best way to re-add the child on a failed delete.

RockfordLhotka replied on Wednesday, June 27, 2007

Technically to do an "undelete" you should call CancelEdit on the collection itself - thus restoring deleted items back to the list.

bearntrail replied on Thursday, June 28, 2007

Well, I'm doing something wrong then. (Probably many things wrong.)

I tried a CancelEdit() on the collection, but it didn't recover the deleted item from the DeletedList. Looking further, the EditLevel was 0 in the collection object prior to the CancelEdit.

So, I tried to do a BeginEdit() on the collection prior to assigning it to the binding source. But, when I try to save the changes, I get a CSLA validation exception "Object is still being edited and can not be saved".  So, before the save, I added temp.ApplyEdit() to the cloned collection.  Then, if it succeeds, I ApplyEdit() on the original collection. If it fails, I do CancelEdit() on the original collection.  Then, when I re-bind the datasource, I again do a BeginEdit(). 

This works, except that ResetBindings(false) bumps (only) the first collection object's EditLevel by 1, and subsequently give me a "Edit level mismatch in CopyState" (CSLA v3.0 Beta2) exception when I try to do the BeginEdit() on the collection.  If I ApplyEdit() on the first object in the collection prior to doing the BeginEdit on the whole collection, everything seems to work... but I don't want to leave it that way.  Any suggestions?

 

 

 

ajj3085 replied on Thursday, June 28, 2007

Well you shouldn't be calling the xxxEdit methods on the collection directly ever.  You shouldn't need to call Beginedit at all, the BindingSource will do that.  Try just calling cancel edit on the bindingsource and see if that solves your problems.

bearntrail replied on Thursday, June 28, 2007

I removed the BeginEdits on the collection and tried the CancelEdit on the binding source.  Again, it did not recover the item from the DeleteList... the EditLevel is 0 after I assign the collection to the binding source.  I'm thinking this is the source of my problem. 

Before I get to my test case, I'm re-using the DataGridView to display two prior collections.  I notice the first time I assign the first collection to the datasource (and hence the DataGridView), the EditLevel is changed to 1. (this is good)  Then, in moving on to the next collection, I do an EndEdit on the datasource, assign it null, and then assign it the second collection, on my way to my test case. At this point, the EditLevel is 0.  The same happens when I finally get to my test case collection. So, I end up with a DataGridView that uses a DataSource where the underlying collection has an EditLevel of 0.  Which I think is not good, and the reason the CancelEdit on the datasource does not un-do.  Am I on the right track?

RockfordLhotka replied on Thursday, June 28, 2007

What is your root object?

 

If your root is a BB, with a child BLB of children, then you should never have to call ___Edit() yourself.

 

If your root is a BLB then you may need to call ___Edit() yourself, but you must do it BEFORE and AFTER data binding. In other words, call BeginEdit() before hooking up data binding, and only call CancelEdit() or ApplyEdit() after you’ve disconnected data binding.

 

You can see an example of doing this in the BLBTest sample app’s Form1 code.

 

Rocky

 

 

From: bearntrail [mailto:cslanet@lhotka.net]
Sent: Thursday, June 28, 2007 2:44 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Proper way to handle deletes in a DataGridView?

 

I removed the BeginEdits on the collection and tried the CancelEdit on the binding source.  Again, it did not recover the item from the DeleteList... the EditLevel is 0 after I assign the collection to the binding source.  I'm thinking this is the source of my problem. 

Before I get to my test case, I'm re-using the DataGridView to display two prior collections.  I notice the first time I assign the first collection to the datasource (and hence the DataGridView), the EditLevel is changed to 1. (this is good)  Then, in moving on to the next collection, I do an EndEdit on the datasource, assign it null, and then assign it the second collection, on my way to my test case. At this point, the EditLevel is 0.  The same happens when I finally get to my test case collection. So, I end up with a DataGridView that uses a DataSource where the underlying collection has an EditLevel of 0.  Which I think is not good, and the reason the CancelEdit on the datasource does not un-do.  Am I on the right track?



Copyright (c) Marimer LLC