New to CSLA - Editing a row in grid.

New to CSLA - Editing a row in grid.

Old forum URL:

AndyW posted on Friday, March 07, 2008



Please could someone point me in the right direction.

I have successfully created a ERLB and succesfully bound that to a grid.  I am able to edit / add / and delete.

However, I require advice on the following, what I want to do is load a form when I double click a row in the grid and pass the current row to the form and when the form is closed update the values in the grid.

How would you pass the row to the form? would you send the item as a BusinessBase?

Anyhep would be appreciated.



ajj3085 replied on Friday, March 07, 2008

What are you trying to acomplish by having the other form?  I would say the form should expect whatever type is stored in the ERLB.  I'm not sure how to update values in ERLB though without triggering a delete and update (to a value which doesn't exist).  ERLB exists for one use case; when each row in a Windows grid needs to be saved independantly of each other.  That's it.. so what you need to do depends on what this other form should do.

rsbaker0 replied on Friday, March 07, 2008

I'm not sure how to update values in ERLB though without triggering a delete and update (to a value which doesn't exist). 

If the form is actually bound to an object in the ERLB, the grid that is showing the ERLB will synchronously show all the property changes made on the form (at least ours does).

We let the ERLB save the objects, so it's never out of sync with what is displayed on the form (and we rebind the object on Enter event of the form so it's never stale). It seems to work well.

ajj3085 replied on Friday, March 07, 2008

Oh ya, good point.

rsbaker0 replied on Friday, March 07, 2008

Your form should (could) have a BindingSource object created (in the designer) using a data source that is of the type of object you want to edit. (You can put your BO's in the designer as data sources and just drag fields onto your form)

The BindingSource itself doesn't care about the type of object you attach to it. You can actually assign the ERLB itself to the BindngSource.Datasource member, and the bindings will do the rest, for the most part. (Assigning the current row of the ERLB to the Datasource will also get editing going).

There is a Pandora's box here if you have the IEditableObject interface enabled. Some grids will save any time you leave the row, including going to your form, so it's possible that depending on what you are doing that the object reference the form is using can be stale almost immediately because ERLB may auto-clone your object and save the clone.

If you are doing editing your self, then you can just call BeginEdit and ApplyEdit your self as necessary (e.g. when your form closes). ERLB object rows will automatically save when their edit level goes to 0.

If you are going to leave your form up (e.g. Apply and continue editing), then you need to unbind your object during the save and rebind afterwards. There are many posts here on this forum -- search for "rebind".


AndyW replied on Friday, March 07, 2008

rsbaker0 thanks, you have got me going in the right direction, and in most part it's working, but I have opened pandora's box :-)

Based on your suggestion I will search the forum and look at rebinding.

Once again thanks.


rsbaker0 replied on Friday, March 07, 2008

Glad it was helpful -- I'm pretty new at CSLA (not quite a year) but the issue with editing from a grid has been something we've been giving a fair amount of attention.

Right now, we're letting the built-in IEditableObject interface handle the editing (e.g. the databindings will automatically call BeginEdit() when you change anything, and the grid automatically does BeginEdit()/EndEdit() calls as you navigate between rows or leave the current row, which works, "sort of".  In fact, I think it would work fine for certain types of UI models.

We're trying to evolve into a "browser style" of navigation where the user can traverse just about any relationship (parent, using, child, don't care) and basically hyperlink around anywhere they want, and I don't think it this approach is going to work. You also can turn off support for IEditableObject and completely do your own BeginEdit/ApplyEdit calls and manage saving yourself, which is what we will probably end up doing.


stanc replied on Monday, March 10, 2008

We have a similiar interface, but we did disable IEditableObject. We did that because we wanted to have full control of when the object is saved, deleted, or rolled back.

Copyright (c) Marimer LLC