views:

356

answers:

5

I've got a couple of codes to do some things but I need to create a function that undoes the previous task/addition/change.How do I do this in Borland C++?

(the program stores strings of text in a text file using "list",it is stored and then erased unless I use the save-function I've created)

right,so I don't know if I've forgotten to mention anything of importance for you to be able to help me better,but if there's something you're wondering about the functions just ask.

I meant creating an undo function in a simple consol application by the way.

+2  A: 

you can store snapshots of state. state is set of data that action can modify. when you click undo current state is replaced by previous. actually it is not trivial task, especially if state is complex.

Andrey
+3  A: 

Also see the memento pattern. Sometimes the intelligence that must go into a command to undo an operation is pretty involved. Drawing objects in a paint program for example. It can be easier just to store a memento and then restore from that memento to implement undo.

Noah Roberts
+9  A: 

To implement Undo, you need to create an "action stack" in your application. There are two basic approaches, though:

  1. Knowing your baseline (the last time the file was saved, or since the file was created), remember every single change that was made so that when something needs to be undone you just throw away the "top-most" item and regenerate the current view from the baseline plus all of the changes. Clicking "Redo" then just puts that item back on the stack. This has a side benefit of being able to trivially remove items anywhere in the stack without messing up other undo/redo options, although there will be special care needed to make sure that the application of "higher" states is as the user intended.

  2. For each action, store off the change that was made to the previous state as well as the change that would be necessary to restore that previous state if you were to undo. Now when the user clicks "Undo," just do the "undo" steps. When clicking "Redo," reapply the changes that were made. In some cases the "Undo" steps will be "here's what the thing looked like before," but that can cause havoc if you want to allow users to remove items that are not on the top of the stack and then need to remove something above it.

The proper choice depends on a lot of factors, including how much data you can/will carry around. Option #1 is in some sense easier but it could become very slow to undo anything if the action stack is large.

dash-tom-bang
It seems you got outvoted on this one but I like your line of thought. Especially you're the only one who considered the issue of wanting to undo something that's not at the top of the stack, which is far from trivial!
Matthieu M.
Thanks, and yeah, the other responses pointed to patterns but didn't actually discuss them. That is all fine and good but I'm not a huge fan of trying to fit patterns to problems as a starting point. Usually (for me, using TDD) it works the other way; a pattern is revealed once the solution is reached.
dash-tom-bang
+7  A: 

I'll give yet another answer, but I think that the coverage has been insufficient so far.

The subject is far from trivial, and googling it returns a good number of results. Many applications implement a "undo" operation, and there are many variants.

There are 2 design patterns which can help us out here:

  • Command: it's a reification of an action
  • Memento: which consists in storing state (usually implies some form of serialization)

The Command pattern is heavily used in graphic environments because there is usually various ways to accomplish an action. Think of save in Microsoft Word for example:

  • you can click on the save icon
  • you can go into File menu and click on Save
  • you use the shortcut, typically CTRL+S

And of course save is probably implemented in term of save as.

The advantage of the Command pattern here is twofold:

  • you can create a stack of objects
  • you can ask every object to implement an undo operation

Now, there are various issues proper to undo:

  • some operations cannot be undone (for example, consider rm on Linux or the empty trash bin action on Windows)
  • some operations are difficult to undo, or it may not be natural (you need to store some state, the object is normally destroyed but here you would need to actually store it within the command for the undo action)
  • generally we think of undo/redo as a stack, some software (graphics mainly) propose to undo items without actually undoing what has been done afterward, this is much more difficult to achieve, especially when the newer actions have been built on top of the to-undo one...

Because there are various problems, there are various strategies:

  • For a simple Command, you might consider implementing an undo (for example, adding a character can be undone by removing it)
  • For a more complex Command, you might consider implementing the undo as restoring the previous state (that's where Memento kick in)
  • If you have lots of complex Command, that could mean lots of Mementos which consumes space, you can then use an approach which consists in only memorizing one Snapshot every 10 or 20 commands, and then redoing the commands from the latest snapshot up to the undone command

In fact, you can probably mix Command and Memento at leisure, depending on the specifics of your system and thus the complexity of either.

I would only considering undoing the last action executed to begin with (using a stack of action then). The fonctionality of undoing whatever action the user wishes is much more complicated.

Matthieu M.