The most obvious strategy, I think, would be to “remember” the actions you take. You need to think very carefully about the construction of the object that represents your application’s state. So, for example, if you are performing drawing operations on a surface, you would need a Surface class with a variable, or set of variables, that held operations performed on the surface in the order that they are performed – it’d look something like a stack, in fact. This isn’t going to be easy because of the varying number of parameters that might be associated with each action. Maybe you’d have to store the operation as a string and parse it on an undo/redo. You’ve also got to have an equivalent reversal for each action. This may mean you have to store further data in your object. Maybe you need a set of pointers to functions (Hmmm) – that probably means delegates in .NET terms.
You’ll also have to maintain a pointer into your stack so that you can do multiple undos and redos, if that’s what you want to do.
I think I’d be tempted to solve the problem for one undo/redo before going on to perform arbitrary numbers of undos/redos. This might even suggest a recursive solution.
Not a trivial problem – unless I’m over-complicating it. It’ll be interesting to see what other people can come up with. It is a fault with me that I tend to miss easy solutions.
HTH
Peter
Personally, I would not rewrite the majority of this, as it has already
been done countless times....reinventing the wheel and all that....
Check out this link, which shows how to use xml to handle your
redo/undo stuff:
http://www.informit.com/articles/article.asp?p=25047&rl=1
Cheers,
Mark