BindingSource.DataSource and EndEdit() issues

opedog posted on Monday, May 05, 2008

This isn't per se a CSLA specific question, but I wasn't sure where else to turn. What I have is a very simple set of processes all conspiring against me. Here goes:

In my UI I have a display only control with a BindingSource that just shows some of the members of one of my business objects. As such, I set the BindingSource.DataSource to be my business object and voila, the control is populated. However, since the control is readonly I immediately call BindingSource.EndEdit(). There's no reason to keep the edit level incremented in this case because for some reason setting BindingSource.DataSource calls BeginEdit().

Then I open a modal to actually edit my original business object. This modal also contains the same control as above to display the data of my business object. Upon opening the modal, I call BeginEdit() on my business object to increment it's EditLevel. Later on I populate the readonly control above. This time, however, after I set BindingSource.DataSource to be my business object, the BindingSource does NOT increment the EditLevel. I then immediately call BindingSource.EndEdit() again assuming the BindingSource on the readonly control has again incremented the EditLevel, only to have it decrement the EditLevel (since it's applying the changes that were made).

My question is, how do I know whether or not the EditLevel of my business object was incremented by my readonly control? I can obviously do some ugly reflection to get the EditLevel out, but surely there is a better solution. Maybe a better question is, once I set BindingSource.DataSource, doesn't my business object get put into a synchronization object? If so, can't I check it to see if it's already in there and to not call BindingSource.EndEdit() since it didn't increment the EditLevel? Hopefully someone has dealt with this before so my rambling actually makes sense to them. :)

Any help is greatly appreciated as this is really stumping me.

Thanks!

Oh, and I'm using CSLA v2.0.

triplea replied on Tuesday, May 06, 2008

Here are a couple of suggestions, I hope they are of some help:

- Upgrade to CSLA 3.x. I beleive a lot of enhancements were made from 2.x to 3.x regarding edit levels, which made debugging them a lot easier. Since there are no major breaking changes, you might want to consider upgrading first and then retackling this issue.
- In the caseof your modal window. I take it you pass your object as a parameter to your window and bind/edit it in there. What you might be better off doing is call the UnbindBindingSource method (as per the PTracker example) on your parent window to unhook the object from any bindings. You could pass the apply flag as true/false, it shouldnt really matter. Then within your modal window bind and eventually unbind the object following the proven guidlines and finally, after closing the modal window bind the modified object back on your parent form.

Hope this helps...

opedog replied on Tuesday, May 06, 2008

triplea:
Here are a couple of suggestions, I hope they are of some help:
- Upgrade to CSLA 3.x. I beleive a lot of enhancements were made from 2.x to 3.x regarding edit levels, which made debugging them a lot easier. Since there are no major breaking changes, you might want to consider upgrading first and then retackling this issue.
- In the caseof your modal window. I take it you pass your object as a parameter to your window and bind/edit it in there. What you might be better off doing is call the UnbindBindingSource method (as per the PTracker example) on your parent window to unhook the object from any bindings. You could pass the apply flag as true/false, it shouldnt really matter. Then within your modal window bind and eventually unbind the object following the proven guidlines and finally, after closing the modal window bind the modified object back on your parent form.

Hope this helps...

Thanks. :) I've mentioned to my boss about upgrading to CSLA 3.0.4. We'll see if that goes through.

Another thing I noticed in my testing. I did the ugly reflection stuff to see if I should call EndEdit(), so my EditLevels are now working correctly, however, sometimes when CancelEdit() is called explicitly on the business object it doesn't decrement the EditLevel. Is this a CSLA 2.1.1 bug as well?

opedog replied on Tuesday, May 06, 2008

I think this is the answer to my problem. :)

From the CSLA 3.0.2 change log:

The subtle change is this: prior to this change, a manual call to BeginEdit() would prevent a subsequent IEditableObject.BeginEdit() call from having any effect, leaving the object at edit level 1. With this change both the manual and IEditableObject calls will take effect, putting the object at edit level 2. In reality, this change makes the behavior more clear and consistent, but since it is a change it could break some code.