DataGridView Child not Saved on Form Close

The binding is automatic. But if you look further in the data binding chapter you’ll see that you can’t call Save() until you have unbound the objects from the bindingsource controls. You must first unbind the child, then the parent. And unbinding takes a bit of code, especially for collections, because you must explicitly call CancelEdit() or EndEdit() on the child.

Rocky

I see, sorry…

I have never tried to figure out the UI code necessary to use ERLB with child objects, so you are in uncharted territory.

But you can extrapolate from PTWin the fact that you’d need to unbind the child bindingsource before the root object could be saved. You aren’t calling Save(), but ERLB is calling Save(), so Save() is being called. The object (and its children) must be unbound before Save() can be called.

ERLB takes care of “unbinding” the object before Save() is called. But it doesn’t know that there are child objects involved, or child bindingsource objects. So you must detect that the root object is about to be saved, unbind the child bindingsource, allow the Save() call and then rebind the child bindingsource (probably to a new set of children from the new root).

Your manual EndEdit() call is more or less what I’m talking about, but it isn’t quite right. Where you do the EndEdit() call you need to actually unbind the child collection. Otherwise what happens is that your EndEdit() is immediately followed by an automatic BeginEdit(). Yes, your changes are saved, but that one child object is actually still at an elevated edit level, and there’ll almost certainly be some unpredictable end results if the user leaves a row (at the root leve), then returns to that row, because that row has one child already at edit level 1 or 2, which will be pushed yet higher if it is edited – in the end you’ll get some odd results.

To avoid that, where you are calling EndEdit(), replace that with a call to UnbindBindingSource() from PTWin, and then make sure to rebind once the Save() call is complete.

Rocky

This is true with a simple ERLB where each root has no child objects?

Or to put it another way, there’s a project in svn in the samples/trunk/ERLBTest folder that I use for testing ERLB and data binding. I don’t have time to look in the near future, but if you could confirm the issue exists in that test app that’d be very helpful!

svn://svn.lhotka.net/csla/samples/trunk/ERLBTest

Rocky

I know I am in uncharted territory and you have lot on your plate at the moment but I just thought I would make a note of an issue I have come across just in case you have time to look at it.

The issue concerns invoking a row undo with the Esc key when a datagridview is bound to an editable root list base. The undo works fine the first time a row is visited but does not seem to work on the second visit. This is only a problem with Csla 3.0.3. Using Csla 2.1.4 the undo works all the time.

Regards,

Patrick

No problem :)

You need to use something like TortoiseSVN to access the repository using the svn:// URI. That will allow you to do a checkout of the code to your machine.

http://www.lhotka.net/cslanet/Repository.aspx

Rocky

Forgive my stupidity – I have navigated to http://www.lhotka.net/cslacvs/viewvc.cgi/samples/trunk/ERLBTest/

Which is what I assume is the same as

svn://svn.lhotka.net/csla/samples/trunk/ERLBTest

but cannot work out how to download it.

Regards,

Patrick

ERLB (and Csla.Wpf.CslaDataProvider) clones the object because the only safe way to save an object when using a local data portal is to save a clone.

CslaAutoCloneOnUpdate tells the data portal to do that clone, and the data portal can be smarter about it (because it knows whether the data portal is local or remote).

If you are using a local data portal and you don’t clone the object before saving, then any exception that occurs during the save will leave your object in an indeterminate state. In earlier versions of CSLA I didn’t force the cloning for performance reasons – but the resulting behavior is incorrect, and so I’m phasing in the requirement to do the cloning. In CSLA 3.5 the auto-clone behavior is turned on by default (the reverse of 3.0 where it is off, but you can and should turn it on).

Rocky

Thanks for the pointer Rocky; I think I have solved it.

No your ERLBTest project does not exhibit the problem.

Your ERLBTest project had CslaAutoCloneOnUpdate set to True. As soon as I did this in my project the problem went away.

I think this is because the ERLB creates a clone of the business object in the SaveItem method if this config item is not set to true. The BindingEdit flag on the business object is set to false after the call to AcceptChanges in BusinessBase.ApplyEdit i.e. after the clone has been created. So the BindingEdit flag is still true in the cloned object that is now in the collection. Next time the row is visited a snap shot is not taken during the call to IEditableObject.BeginEdit as BindingEdit is still true.

Does this make sense? If so, is it easy to say why the ERLB takes this clone if CslaAutoCloneOnUpdate is not set?

Regards,

Patrick