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: [email protected] Web Site: http://www.sonsothunder.com/ _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
