Creating an Undo palette
bobs at twft.com
Thu Dec 8 11:40:39 EST 2011
If there were a property that contained all of the standard properties of an object, you could simply store the array for that object in another array with 4 keys: The first being the version of the undo (for multiple undo's), the long id of the object, the defaultProperties (??) of the object, and the customProperties of the object. Here is where storing keys in an array in the order they were added would be REALLY handy, but alas, Livecode don' play dat!
It's not very efficient storing both property sets in full, but much simpler to work with. This way you would not have to trap for every change a user could make to an object.
On Dec 8, 2011, at 8:02 AM, Ken Ray wrote:
> On Dec 7, 2011, at 1:28 PM, Alejandro Tejada wrote:
>> Hi All,
>> I am trying to create an Undo function
>> for one of my stacks.
>> Not sucessful at all. Everything seems so simple,
>> but it failed everytime.
>> The model that I am using for this task is the
>> "History palette" used in Photoshop:
>> Now, I am asking for advice from all of you
>> that have created similar function for your
>> applications or stacks.
> Al, I've done that for my Stykz animation program, but only focused on objects (it doesn't do any text undoing). You basically need to store the state of an object before it is manipulated by the user so that you can reinstate the same state after it's 'undone'. With the exception of actions that physically destroy an object (like a "cut" or "delete" command), the methods to choose from would fall into these three categories:
> 1) Using 'save' and 'revert'
> 2) Store a physical copy of the original object, and then copy it back again on an "undo"
> 3) Storing/restoring all the properties of an object
> #1 is very touchy and doesn't give you the ability for multiple undos/redos (which would seem to be your intention with the History palette), so you can ignore that one.
> #2 could be used, but you're deleting and copying objects which will use up object IDs rather quickly, and it is also a pain if the objects in question are inside of a group at a specific layer in the group.
> #3 seemed to be the best choice for me, with #2 being used only when the user wanted to cut or delete an object (I have an offscreen stack I use to hold the objects in that instance.
> Basically you want to store the properties of an object *before* they are manipulated by the user; if someone's doing that through an interface (like changing the fill color of a graphic), you can store the old fill color before you change it to the color they selected. It's a little trickier with resizing/moving objects themselves, but it can be done. It's more of a pain if you're giving the user the pointer tool, but it can be done there as well. The bottom line is you need a message you can trap that will take place *before* the user's action, then store the relevant property(ies) in your undo history list, and then let the user's actions take place.
> Hope this helps,
> Ken Ray
> Sons of Thunder Software, Inc.
> Email: kray at sonsothunder.com
> Web Site: http://www.sonsothunder.com/
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode