I'm looking for a "best practice" on a particular binding model.
You have a split screen display with an ERLB on the left, and a child collection of the current ERLB object on the right. As the selection on the left changes, the current child collection is displayed on the right. If you click on another ERLB object, changes made to the previous one are saved.
The "problem" I am having is that when you click on a child, the grid control for the ERLB does an ApplyEdit (and hence Save) on the current object, and the child collection shown on the right is "orphaned" before you ever make any changes to it.
I can bludgeon my way through this -- the CSLA objects tolerate BeginEdit() calls almost arbitrarily, but I was wondering what the recommended approach was. What I have been doing in similar situations is to do rebind on the Enter event for the control used for editing the child object or collection, but I'm not sure if that is the right thing to do.
Do your bindingsource controls have a parent-child relationship? I'm guessing not, which would be why the parent bindingsource thinks it needs to do an EndEdit when you switch focus to the other bindingsource (though I'm guessing on this).
Certainly though, if you have a parent-child relationship with two grids, you can click in the child grid without triggering a currency change in the parent grid - but I assume that's because the bindingsource controls understand the relationship?
RockfordLhotka:
Do your bindingsource controls have a parent-child relationship? I'm guessing not, which would be why the parent bindingsource thinks it needs to do an EndEdit when you switch focus to the other bindingsource (though I'm guessing on this).
Certainly though, if you have a parent-child relationship with two grids, you can click in the child grid without triggering a currency change in the parent grid - but I assume that's because the bindingsource controls understand the relationship?
No, the controls are two grids side by side separated by a splitter. Each as its own bindingsource.
However, now that you mention it, we found that the grid control we are using (DevExpress) calls EndEdit() on the parent when you click on a child detail grid that it is managing (e.g. the parents have a "+" icon next to them and when you expand them, a child grid of the child collection appears). Ugh - I'm not even sure what to do about this, but that's a side issue.
We have some other interfaces with the same grid (double-click on grid row, screen with property sheet and tabs appears next to it) that work automagically just by the IEditableObject calls being made by the grid and binding without any BeginEdit/ApplyEdit calls on our part.
One solution might be to override the default save behavior of
ERLB – making it do nothing. And then add your own save method to do an
explicit save. You can do this by overriding a method in the ERLB base class,
so it isn’t too hard. That would allow your UI to control exactly when
the root object is saved. I don’t know if that’s a good solution,
but it may be worth exploring.
Rocky
From: rsbaker0
[mailto:cslanet@lhotka.net]
Sent: Wednesday, February 27, 2008 9:51 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Help with ERLB split screen binding with child
collection?
Do your bindingsource controls have a parent-child relationship? I'm guessing not, which would be why the parent bindingsource thinks it needs to do an EndEdit when you switch focus to the other bindingsource (though I'm guessing on this).
Certainly though, if you have a parent-child relationship with two grids, you can click in the child grid without triggering a currency change in the parent grid - but I assume that's because the bindingsource controls understand the relationship?
No, the controls are two grids side by side separated by a splitter. Each as
its own bindingsource.
However, now that you mention it, we found that the grid control we are
using (DevExpress) calls EndEdit() on the parent when you click on a child
detail grid that it is managing (e.g. the parents have a "+" icon
next to them and when you expand them, a child grid of the child collection
appears). Ugh - I'm not even sure what to do about this, but that's a side
issue.
We have some other interfaces with the same grid (double-click on grid
row, screen with property sheet and tabs appears next to it) that work
automagically just by the IEditableObject calls being made by the grid and
binding without any BeginEdit/ApplyEdit calls on our part.
One solution might be to override the default save behavior of ERLB – making it do nothing. And then add your own save method to do an explicit save. You can do this by overriding a method in the ERLB base class, so it isn’t too hard. That would allow your UI to control exactly when the root object is saved. I don’t know if that’s a good solution, but it may be worth exploring.
rsbaker,
We're using the DevExpress grid too and I was wondering if you had any issues with it besides what you've posted here so far?
I can tell you that regarding the edit levels we actually "turned off" N-LevelUndo by setting DisableIEditableObject to True.
Thanks,
John
Other than getting used to the unusual programming model, it's been fine.
(Incidentally, if you have any experience doing paging of large result sets with this grid I would be very interested)
The grid actually works well with a similar model to this one except that the other control has real bindings to properties of the parent in addition to child collection grids. When the binding tries to set a value, it automatically puts the ERLB object in the grid back into Edit mode. The child collection grids have similar issues to this one (which I have worked around with a "pseudo" binding), so I'm trying to get educated.
DisableIEditableObject does not "turn off" n-level undo, it mearly tells the BO to ignore calls from databinding. You can still use n-level undo though.
I'll be fully documenting the change, and its ramifications, in the 3.0 ebook, but the property you are looking for is DisableIEditableObject, which is a protected property of BusinessBase. Set that to True and call calls to IEditableObject methods are totally ignored.
Be aware that n-level undo itself is "disabled" unless someone calls BeginEdit(). That could be data binding through IEditableObject, or directly by you.
So disabling IEditableObject does effectively "disable" n-level undo as long as you don't call BeginEdit() yourself.
</Rocky>
![Smile [:)]](/emoticons/emotion-1.gif)
Sigh.
DisableIEditableObject works fine, with me just doing ApplyEdit on the "previous" current and BeginEdit on the "new" current parent object in the CurrentChanged event, but this seems like throwing the baby out with the bath water. Maybe it's just necessary sometimes...
Thanks for your patience the suggestions -- I'll certainly explore the save override route if I reach an impasse but I'm trying to understand the "correct" use of classes out of the box.
Here is what is happening now:
When I click on the child grid on the right, the grid on the left does an EndEdit(), so technically I'm not editing anything and all edit levels are at 0.
If I make any changes to a child on the right, I see an "AcceptChangesComplete" call in my edit level tracing for the child, by I never saw a CopyState call for it (which seems wrong), but is marked as dirty and I know the data is in the object because...
If I click back on the parent grid, the parent with the changed child isn't saved unless I visit the row again after visiting any other row.
Is there a detailed explanation of how the CSLA BeginEdit/ApplyEdit calls are supposed to interact with the IEditableObject calls being made "under the covers" somewhere?
Copyright (c) Marimer LLC