Creating an Undo palette

Pete pete at mollysrevenge.com
Thu Dec 8 12:43:21 EST 2011


I think you could use a timestamp as a key of the array.  The issues of
accessing the elements of the array in time sequence order can be solved by
putting the keys of the array into a variable, sorting the variable, using
each line of the variable as an array key as needed.

Just to complicate things even more - does each user of the application
need their own undo stack or are they all acting on a central pool of data?
 If the former, then the design would need to include some sort of user id
as part of the undo stack.

I wish the LC IDE had a consistent undo stack along these lines!

On Thu, Dec 8, 2011 at 9:03 AM, Keith Clarke <
keith.clarke at clarkeandclarke.co.uk> wrote:

> In this situation - undoes over a period of time - would not a time/date
> stamp within the array provide such a temporal key order?
> Best,
> Keith..
>
> On 8 Dec 2011, at 16:40, Bob Sneidar wrote:
>
> > 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.
> >
> > Bob
> >
> >
> > 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:
> >>>
> http://livedocs.adobe.com/en_US/Photoshop/10.0/help.html?content=WSfd1234e1c4b69f30ea53e41001031ab64-7497.html
> >>>
> >>> 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:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge <http://www.mollysrevenge.com>



More information about the use-livecode mailing list