N-level undo in CSLA 3.0

N-level undo in CSLA 3.0

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


DamReev posted on Wednesday, June 27, 2007

We are having problems with N-Level undo now that we have switched our project to use CSLA.NET 3.0. I can't figure out what to do to prevent us from getting an EditLevel mismatch when attempting to Cancel/Apply Edits in a dialog.

I have an editable Meeting root object which has a child list of Participants. We bind the meeting object via a BindingSource control to various controls on the UI. If you click a button "Invite Participants" we launch a modal dialog which shows all your participants bound to a grid (without using a BindingSource) (Infragistics grid if that matters).

Here's what we do.
1. We call BeginEdit() on the Meeting BEFORE we bind it to the BindingSource.
2. We set the BindingSource.DataSource = the Meeting.
3. User clicks "Invite Participants".
4. We do Meeting.BeginEdit()
5. User makes edits in modal dialog (which binds list of Participants to a grid, details about the participants are not editable, at least not at the moment but Participant derives from Businessbase, ParticipantList derives from BusinessListBase)
6. User presses OK/Cancel and we do EndEdit()/CancelEdit() on the Meeting.

This doesn't work, can anyone give some guidance in what to do. I've read the other posts on N-Level undo and unfortunately I'm stilling not having that "AhhHa moment".

Thanks

RockfordLhotka replied on Wednesday, June 27, 2007

You should look at the ProjectTracker sample - specifically ProjectEdit or ResourceEdit in PTWin.

You must not call BeginEdit, CancelEdit or ApplyEdit on the object ever.

Instead you must call the methods on the bindingsource - and even then you never call BeginEdit yourself, as it is automatic.

 

The alternative is to turn off IEditableObject processing. That is a new 3.0 property you can set on each business object (probably in the constructor, though you could also do it before binding the object to your UI. If you set that property then the rules are reversed: you must call BeginEdit, CancelEdit and ApplyEdit yourself.

The drawback to this manual approach, however, is that you lose in-place editing capabilities in grid controls, because you can't get into the process deep enough to call the edit methods at the right points (at least not in my experience).

Copyright (c) Marimer LLC