This project has moved and is read-only. For the latest updates, please go here.


Dec 9, 2011 at 7:56 AM

Nice project! Thank you!

One small suggestion:

In  DefaultChangeFactory.OnChanging(object instance, string propertyName, object oldValue, object newValue) I would add property "description", because inconvenient use propertyName as description :)

Dec 9, 2011 at 2:05 PM

Hi @sijei,

Thanks for the suggestion. Adding the description sounds like a good idea. I'll take a look and try to get that change made.

- Nathan

Dec 9, 2011 at 2:07 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jan 31, 2012 at 3:05 PM

This change has been made and is available in the release.

Thanks for the feedback!

Mar 13, 2012 at 4:58 PM


I think it would also be useful to have in this method two object instances instead just one defined at first parameter:

- the first object instance that implements ISupportsUndo and stores Undo and Redo stacks (just as it's defined now because OnChanging method implicitly requires the first parameter to implement ISupportsUndo),

- the second object instance would be a reference to the object that stores the property which is changing; this reference would be used (by reflection) to restore previous value at Undo() or Redo()


The situation in which it would be useful is when you have some class, lets say MyClassA, that implements ISupportsUndo and this class has a property of some complex type, lets say MyClassB, which should have a common UndoStack with MyClassA. The reason to have a common UndoStack could be for example like this: MyClassB defines some complex property which has to be edited through nested control. This nested control gets only the reference to property defined in MyClassA and in fact this property doesn't even has to have a setter, because nested control is fed by MyClassA getter 

Now the only solution to this problem I see is writing a setter in MyClassA and within this setter store the changes of MyClassB instances. But this doesn't seem to be very effective solution :)  I think additional parameter to OnChanging method would solve this issue :)

Mar 13, 2012 at 7:26 PM

Hi @tuvok,

I think I understand your scenario. Can you take a look at the unit tests in the source code to see if this is handled via a slightly different approach?

The unit tests include scenarios where the RootDocument instance that has one or more children (ChildA and ChildB). If you look at ChildA ( you can see that ISupportsUndo.GetUndoRoot() returns a reference to the instance of the class named RootDocument.

ChildA returns it's "parent", which is the instance of RootDocument. This object is the "key" that is used for all changes that occur to the RootDocument or it's children. As a result, calls to UndoService.Current[key] will return the same undo stack for all objects in the hierarchy. So, in a sense, the RootDocument and it's children use the RootDocument instance as a common "key" that is passed to the UndoService when getting the UndoRoot. And it is this UndoRoot instance that has the undo stack.

Does that make sense? It just requires that your "child" instances have a reference back up the object hierarchy to access their "parent" instance.


Mar 13, 2012 at 11:24 PM

Hi Nathan,

I think that covers my case :) Honestly, I feel a little bit ashamed, because the solution seems to be straightforward... I don't know why I didn't try this instead of writing on the forum :|

Thanks :)

Mar 14, 2012 at 1:15 AM

No Problem, and no need to feel bad. My documentation and samples need some work.

Please let me know if you have any other questions, comments, or concerns.

- Nathan