Editable Root Lists, grids, and binding?

Editable Root Lists, grids, and binding?

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


rsbaker0 posted on Tuesday, October 07, 2008

I have use case that seems to break some CSLA "rules" on one hand, but on the other hand it seems to work in most but not all cases.

I have a ERLB set as the data source for a grid, side by side with an optional editing form for the current row.

 The BindingSource.DataSource for the form is set to the Current property of BindingSource for the grid, and I handle cloning issues by being sure that I repeat this assignment anytime the form gets the focus (Enter event).

The short story is that I'm never calling BeginEdit/ApplyEdit, etc., but the grid properly saves each object as you move from row to row.

There is some strange magic going on here because (1) the grid will automatically call IEditableObject.ApplyEdit whenever you leave the current row or the grid loses focus, but (2) The bindings for the form for individual fields automatically call IEditableObject.BeginEdit as soon as you make any change to a bound control.

So, it seems to work very well as long as I'm editing a field bound directly to a root object property. I get into trouble if I'm editing something that either doesn't have a direct binding or is a child object of the root, because IEditableObject.BeginEdit never gets called on the root. I can "force" it to work by calling IEditableObject.BeginEdit manually when the form gets the focus, but I'm not sure if this is a good idea.

Any thoughts on the proper way to go about this?

rkelley replied on Tuesday, October 07, 2008

What type of grid are you using? I had some very strange issues with an Infragistics grid when I was editing a collection with grandchildren. The edit levels always got out of whack so I ended up having to disable IEditablObject on that object and its children so that I could manage it directly, at the appropriate times.

rsbaker0 replied on Tuesday, October 07, 2008

It's a DevExpress XtraGrid.

The grid is currently only showing the root objects, but I have child collections and objects that do "manual" binding on the form (really a set of tab pages, but same idea).

I've done the DisableIEditableObject route in some other use cases, but this one seems to work OK except with child objects and unbound fields.

FatPigeon replied on Wednesday, October 08, 2008

I have been doing a lot of work recently trying to get a standard approach to multi generation grid forms (i.e. parent grid - child grid - grandchild grid) and have arrived an approach. I am using CSLA 3.5 and the system.windows.forms.datagridview.
 
I still have a couple of problems such as:
 
I cannot stop EndEdit being called when focus moves from the root grid to a child grid.
I can stop the root grid moving to a new row when an error has occurred while attempting to save except by stopping the focus moving from the current grid row or current control while an error exists.
 
The approach is therefore probably not suitable when:
 
1    It is not acceptable to have a parent saved before the children have been edited.
2    The object profile has complex rules depending on more than one field or business class instance (i.e. business class instance with the current object profile).
 
But I think it is suitable for general database browsing and editing.
 
I don't know if it is the 'proper way', but basically I let IEditableObject methods be called by the grid/grid binding infrastructure. I have overridden the root business class save method as I find I need to fiddle with the setting of Csla.Core.UndoableBase.BindingEdit on a root instance after calling base.Save, inorder to ensure BeginEdit is always called after a save and to get the edit level right.
 
Please let me know if you would like more details.
 
Regards,
 
Patrick

Copyright (c) Marimer LLC