Creating an Undo palette

[Ken Ray]

On Dec 8, 2011, at 11:29 AM, Bob Sneidar wrote:

> I thought this over, and there would be problems. First, the ID of an object is part of the default property set. I can imagine there are a number of read only properties that only the engine can write to, so it would not be as simple as storing the entire property set and then restoring it. 

You wouldn't have to store *ALL* the properties of an object - just the ones that the user is able to change; as I mentioned, if you are providing an interface to make the change, you can control what you "remember" about an object… so that leaves properties that you allow the user to change without a separate interface element getting in the way, like resizing with the pointer tool or typing text into a field. These give you messages you can trap, but you're not giving someone a special UI to change these properties (usually).

> One other kink I just thought of is the issue of closing unsaved stacks. What if your user closes the stack without saving? You would have to be able to go back to the point before the user last saved the stack.

Actually you wouldn't - you'd purge the "undo list" at that point since the next time they open the stack you're starting a new "undo list".

> Also, if the user saves the stack, you would have to wipe the array so as not to "undo" into a now defunct version of your stack. 

Yes, you'd want to wipe the "undo list" after a stack was saved or after some other action that you can't "undo".

Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/