Nov 13, 2011 at 1:18 AM
Edited Nov 13, 2011 at 1:20 AM
I believe that you having these issues because something wrong with application design.
to GreatBigBrain: If you do not want a property to participate in Undo/Redo command, then just make it as a regular property, do not use UndoRedo<> class to declare it.
to scottgblood: In your case you have to make a single command where you will initialize the object and drag it into canvas. do not make to separate command to initialize the object.
In general, you cannot have non-undoable change in the middle of sequence of undoable changes:
undoable change 1
undoable change 2
undoable change 3
non-undoable change A
undoable change 4
undoable change 5
it simply breaks the common sense. Just pretend what what will be if we rollback to the point "undoable change 2"...
Will it be the an equivalent of state after original "undoable change 2"??? Answer is no.
It will be an "undoable change 2" + "non-undoable change A". It breaks the whole concept of the COMPLETE and CONSISTENT rollback.
If this concept does not correspond to your design -- believe me: something is wrong with the design, not with the concept.
I created an application with canvases and draggable objects. I stumbled against the same "issues". Eventually I came up to the right design where non-undoable part of application has to be TRANSISTENT and CALCULATABLE from undoable part. It means application
must be able to restore its complete state and appearance SOLELY from undoable part.
In some exceptional cases when you have some data that cannot be undone - it should not interfere with undoable data anyway. But if you cannot avoid the dependency and undoable data DEPENDS ON non-undoable data, then command stack has to be cleared
when non-undoable data changes. But it is a rare situation, MUCH more likely you just got wrong design. Reconsider twice before you decide you having this case.