N-LEV EL UNDO in C#

Creator PDF-417 2d barcode in C# N-LEV EL UNDO

Figure 13-2. Edit process in which objects are removed and CancelEdit is called Another common scenario follows the same process but with a call to ApplyEdit() at the end, as shown in Figure 13-3.

The first two steps are identical, of course, but after the call to ApplyEdit(), things are quite different. Since changes to the collection are accepted rather than rejected, the changes become permanent. Child A remains marked for deletion, and if the collection is saved back to the database, the data for child A is deleted from the database. Child B is totally gone at this point. It is a new object added and deleted at edit level 1, and all changes made at edit level 1 are accepted. Since the collection knows that B was never in the database (because it was added at edit level 1), it can simply discard the object entirely from memory. Let s look at one last scenario. Just to illustrate how rough this gets, this will be more complex. It involves nested BeginEdit(), CancelEdit(), and ApplyEdit() calls on the collection. This can easily happen if the collection contains child or grandchild objects and they are displayed in a Windows Forms UI that uses modal dialog windows to edit each level (parent, child, grandchild, etc.). Again, child A is loaded from the database and child B is added at edit level 1. Finally, C is added at edit level 2. Then all three child objects are removed, as shown in Figure 13-4.

Figure 13-4. The result after loading, adding, and removing objects Suppose ApplyEdit() is now called on the collection. This applies all edits made at edit level 2, putting the collection back to edit level 1. Since child C was added at edit level 2, it simply goes away, but child B sticks around because it was added at edit level 1, which is illustrated in Figure 13-5. Both objects remain marked for deletion because the changes made at edit level 2 were applied. Were CancelEdit() called now, the collection would return to the same state as when the first BeginEdit() was called, meaning that only child A (not marked for deletion) would be left.

Figure 13-5. Result after calling ApplyEdit Alternatively, a call to ApplyEdit() would commit all changes made at edit level 1: child A would continue to be marked for deletion, and child B would be totally discarded because it was added and deleted at edit level 1. Both of these possible outcomes are illustrated in Figure 13-6.

Figure 13-6. Result after calling either CancelEdit or ApplyEdit Having gone through all that, let s take a look at the code that implements these behaviors. The DeleteChild() and UnDeleteChild() methods deal with marking the child objects as deleted and moving them between the active items in the collection and the DeletedList object:

private void DeleteChild(C child) { // set child edit level Core.UndoableBase.ResetChildEditLevel(child, this.EditLevel, false); // remove from the index RemoveIndexItem(child); // remove from the position map RemoveFromMap(child); // mark the object as deleted child.DeleteChild(); // and add it to the deleted collection for storage DeletedList.Add(child); } private void UnDeleteChild(C child) { // since the object is no longer deleted, remove it from // the deleted collection DeletedList.Remove(child); // we are inserting an _existing_ object so // we need to preserve the object's editleveladded value // because it will be changed by the normal add process int saveLevel = child.EditLevelAdded; InsertIndexItem(child); Add(child); child.EditLevelAdded = saveLevel; } On the surface, this doesn t seem too complicated but look at the code that deals with the child s EditLevelAdded property in the UnDeleteChild() method. In the InsertItem() method I discussed earlier, the assumption is that any child being added to the collection is a new object and therefore InsertItem() sets its edit level value to the collection s current value. However, the InsertItem() method is run when this preexisting object is reinserted into the collection, altering its edit level. That would leave the child object with an incorrect edit level value. The problem is that in this case, the child object isn t a new object; it is a preexisting object that is just being restored to the collection. To solve this, the object s edit level value is stored in a temporary field, the child object is re-added to the collection, and then the child object s edit level value is reset to the original value, effectively leaving it unchanged.