Click here to Skip to main content
13,091,548 members (71,506 online)
Click here to Skip to main content
Add your own
alternative version


31 bookmarked
Posted 15 Dec 2002

Implementing Undo / Redo - The DocVars Method

, 15 Dec 2002
Rate this:
Please Sign up or sign in to vote.
This tutorial explains a general method for implementing Undo / Redo functionality in an MFC application. The technique allows you to save and cycle undo/redo states within and between editing sessions.

Demo Application


I am pleased to submit a tutorial to the Code Project, as I have benefited very much from the generous and helpful resources here.

This tutorial tries to explain how I developed undo/redo capability for my own applications. It works very well for me; perhaps others here might find it useful. I'll refer to it as the "DocVars" method.

The basic philosophy of the DocVars method is enumerated in the statements below:

  • Packaging - Place all of a document’s undo-able and redo-able variables into a separate class (CDocVars, for example).

  • Handling and modifying the DocVars as a complete package - If one of the variables in the document’s current DocVars needs to be changed, a new instance of the DocVars is created reflecting the change.

  • Serving – Manage a list of CDocVars as the modification of the document proceeds. This tutorial uses CUpdateMgr for this job. Management responsibilities include:

    • Receiving updates of new DocVars from the document and adding them to the list.

    • Sending out listed DocVars to the document in response to Undo and Redo requests from the document.

  • Custodial Duties – A single class must take the responsibility of supporting the CURRENT and LIVE DocVars. This tutorial uses the document as the DocVars custodian. In this capacity, the document is the central clearing-house for the application’s undo-able/redo-able variables. All important variables are maintained by the document, and to gain access to them, all other classes must consult the document.

The conversation below should help to explain how the system works.


Hey, CDocument! What you got?


That all depends on what you want it for.


I need to make a change to one of your variables.


OK, I’m gonna send you a copy of my current DocVars package. Make whatever changes you need. When you’re done, send it back to me.


The whole package?! Geeze! I just want to make one teensy weensy change. Can’t you just send me the one variable I want?




Ok, but it seems like the hard way to do things.


Quit yer complainin’ and get back to work.


Right, I’ve made the change to my DocVars copy. You want it?


Yeah, send it back to me.


What happens now?


I make a unique copy. If the DocVars has pointer variables, I have to allocate memory for new pointers and then fill them up with the parameters from the DocVars you just sent me. Afterwards, I send it along to CUpdateMgr. He adds it to his list and sends a copy back to me when he’s done.


You gotta be kiddin’ me!! What a tangled bureaucracy!! You’re as bad as the Department of Motor Vehicles.


Please just shut yer yapper and let me do my job.


Hello, CUpdateMgr? I got a new DocVars package for ya. Please update your list.


Got it. I'm adding it to the end of the list. Done. Now I’m sending a copy back to you.


Got it. Thanks. The package you returned to me is now my current DocVars.



Hey, CDocument! Some geek with a mouse just clicked the “UNDO” button.


Thanks for the message. I’ll tell CUpdateMgr.


Hey CUpdateMgr! I just got an Undo request.


Okeeday. Let me scroll back one place on the list of DocVars. There it is. Ok, I’m sending you the older DocVars.


Got it, and it is now my current DocVars.



Hey CDocument! What you got?


That all depends. What do you need?


I just need to check the value of one of your DocVars variables.


OK, I’m gonna send you a pointer to my current DocVars.




But you leave them variables alone. NO CHANGES! Ya Hear, BOY!?


Why not?


Because you will completely disintegrate the good thang me and CUpdateMgr got goin’ here, and you’ll ruin the whole Undo/Redo feature.


Roger! No changes. Just lookin’.

Using the code

CDocument or Not

Although the example app uses the MFC document/view setup, the doc/view setup is not a requirement. The trick is to set a single class as the custodian. It doesn’t need to be a CDocument. For example, a dialog-based app could use the main dialog class as the DocVars custodian.


The example app uses MFC serialization. In order to make this possible, CDocVars and all of the DocVars’s class-based variables must support serialization. Since CObject supports serialization, I derived CDocVars from CObject. If you need DocVars variables based on custom classes, consider deriving them from CObject. Just remember that when you derive a new class from CObject, you will need to write a copy constructor for it. In addition, you will need to prepare an assignment operator for (=) and possibly others depending on your needs. See DocVars.h in the example app’s source to see how I did it.


The CUpdateMgr uses a custom list class, CtObjectList. This list class is a template class derived from CList. For me, templates are a bit of a mystery. But one thing is certain, they are extremely convenient. In this example, I had to prepare an (=) assignment operator, and I overrode only the Serialize() function. Please note that CtObjectList expects to handle serializable types. In the present case, it handles CDocVars types which are derived from the serializable CObject class.

Infinite Undo

The Serialize() override function in the CUndo_Redo_DemoDoc class is setup so you can preserve all Undo states to the origination of the document. That is, no matter how many editing sessions you have, you will still be able to Undo to the very beginning. The down side of this feature is that you can end up with pretty hefty files. If this is a problem, I recommend that you place a limit on the number of DocVars in the UpdateMgr’s list and make this a user-configurable value. Or you could simply disable this intersession feature by commenting-out the #define INFINITE_UNDO statement in Undo_Redo_DemoDoc.cpp.


Don’t forget that if you are using pointer variables in your DocVars, you have to associate the pointers in each DocVars with unique spaces in memory. Otherwise, the DocVars pointer variables throughout the list of DocVars all will be pointing to the same memory address – which kinda defeats the purpose. I’ll leave it to you to figure out the best way to do that.


This function is intended to be used mainly as a way for the document to deliver a copy of its current DocVars. This is so the calling function can modify its copy of the DocVars set without directly affecting the document’s current DocVars.


Call this function when you need to find out the value of a variable in the document’s current DocVars. DO NO MODIFICATIONS of DocVars variables while in possession of this pointer. Otherwise, total chaos.

Example MSVS Project

I am supplying the example source code in the form of a Microsoft Visual C++ .NET Solution. Users of MSVC++ 6 might find it easier to create a new SDI/DocView Workspace and then simply add the files from the example.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Tom Morris
United States United States
No Biography provided

You may also be interested in...


Comments and Discussions

Generalgets my vote Pin
DanG16-Dec-02 14:39
memberDanG16-Dec-02 14:39 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170813.1 | Last Updated 16 Dec 2002
Article Copyright 2002 by Tom Morris
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid