0

I've been working on a WPF application that involves moving many shapes. It is mostly MVVM and relies heavily on commands. I had not worried about Undo/Redo until just recently. I don't think it will be too difficult since most of my changes involve commands that inherit a base class CommandBase that implements ICommand.

So far I have added another Interface named IUndoCommand that uses ICommand. I have added an Undo method that will perform the operations needed when an undo is called.

I will be using a stack for both Undo and Redo, but I'm running in to an issue with the parameters for the Execute/Undo methods. Is there a proper way to store these parameters of type object? Is it advisable to add a field/method to IUndoCommand? If so should I set it in the Execute method or in a constructor (if I even can.)

If not should I pass it as it's own object in the Stack?

Secondly, (although this can probably be it's own question) is there a better data structure to track multiple commands? I currently have a loop that runs multiple commands to move multiple selected shapes and would like to allow one undo to undo them all. I guess I could convert this to a command on it's own and pass commands to it, but again I'm new to this and would rather do it right.

Thanks for reading and any help would be greatly appreciated.

Sources:

Code Project VisualStudioMagazine StackOverFlow

Community
  • 1
  • 1
Michael Clausing
  • 52
  • 2
  • 11
  • Have you looked at the Momento Design Pattern? It is specifically for the purpose of undo. Redo would just be the reverse of the pattern as you've done with queues. http://en.wikipedia.org/wiki/Memento_pattern – SASS_Shooter Feb 01 '13 at 18:31
  • I saw that and it is what I originally started working on. I feel like this gives me more control and it works better with what I have done already. I have a DrawingEditViewModel that is set as my datacontext. This has observable collections of viewmodels that interact with the models. It also keeps track of my content width/height and offest (since there is zooming.) There is a possibility that I could move the width/height/zooming to another class, but it would still need to have access to it. – Michael Clausing Feb 01 '13 at 19:58
  • This is a problem as the easiest solution in the momento design pattern is the deep copy the entire viewmodel correct? This would cause zoom-in/zoom-out changes to be saved as a step which would be quite annoying. A user would have to control+z 8 times just to get back to their last view position. I hope this makes sense.. – Michael Clausing Feb 01 '13 at 20:01

1 Answers1

1

Since the interface doesn't need access to the data (it should just need an Undo()/Redo() method pair, and potentially a flag for whether it can undo), it doesn't need to know about the parameters at all.

One option might be to make your implementation of IUndoCommand generic. You could then use this to store the parameter in a type-safe manner.

Your CommandBase class could then be generic, ie:

class CommandBase<T> : ICommand, IUndoCommand
{
    // You could then store the parameter directly...
    public T Parameter { get; private set; }
}
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • I see, I like that solution, but is it ok for me to set it in the Execute method? I would think so, because the Command won't be added to either stack unless Execute is called. I'm just not sure there isn't a better way.. – Michael Clausing Feb 01 '13 at 20:04