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