DeletedList contains objects after .clear

DeletedList contains objects after .clear

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


Charleh posted on Tuesday, June 22, 2010

I have a simple test project which consists of a database with the following relationship

ParentObject -> ChildObject

I have classes to represent my objects in my c# project that look like:

ParentObjectCollection -> ParentObject -> ChildObjectCollection -> ChildObject

I've created a form with 2 gridviews - one bound to the parent collection, and the second bound to the 'children' datamember of this collection.

This works fine - I've handled the AddingNew event of the BindingSource for each databound object so that the dataportal_create method can be used instead of the constructor when a new row is created on the grid. I can also save multiple parents->children without an issue.

I've used a cascade delete from the parent to kill the child rows when a parent is deleted, this also works well.

The issue I have is this:

When I have deleted some items from the parent collection and then run a save on the parent collection, this deletes the parent and the children from the list. I can see that the DeletedList on BusinessListBase is being cleared after the objects have been deleted (via DeleteSelf). However, when I add or remove more items from the grid and try to save again the DeletedList contains all the items which were cleared from the last time I saved, plus any items I deleted since. Of course I could ignore this behaviour as the key being deleted on is a unique integer, however, when I use a table with keys that are not auto generated, I may run into issues.

Is it usually the practice to rebind or refresh the bindings manually after a save operation or is this something databinding should be handling?

Also another quick question - I mentioned before I was handling BindingSource.AddingNew. Should I be using the constructor and letting the BindingSource handle the adds instead of handling AddingNew? As far as I can see I will be adding extra code on forms which shouldn't be there. I see business logic on forms on some of our projects and I think the reason we don't have any segregation between business login and UI code is due to the way we are using CSLA

We used CSLAGen in the past when CSLA 2.0 was out - however, work on the project has pretty much dried up, and without the source there's only so much I can do by template editing

Some of the latest CSLA examples (such as the RootGrandchildWinForms project) seem to be overriding AddNewCore - which I assume is being handled within the CSLA libraries - is this what should be handling databinding adds on the grids?

p.s. I'm currently using CSLA 3.6.1

Charleh replied on Tuesday, June 22, 2010

So rebinding the objects after a save seems to work - I would have thought the object was updated on the bindingsource after a CSLA save - it seems like I'm doing an extra trip to the database to get the object list again even though all I've done in is modified the objects in memory and persisted those modifications to the DB. Surely I shouldn't be making another round trip to the database to get all the objects since the communication was Update from App -> Database

Does this make sense?

RockfordLhotka replied on Tuesday, June 22, 2010

You should use the result of the Save() method - that's the object you should rebind to at the UI level. There is no need to re-fetch the data - Save() returns the updated values.

Charleh replied on Tuesday, June 22, 2010

Ah, that explains it - after using the returned object everything is working as it should, thanks Rocky

Copyright (c) Marimer LLC