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.
So another approach would be to create a constant or system global with the names of the properties you DO want to be able to undo. This way you could loop through just the properties you care about, adding more later by updating the constant. You could check the new props against the last version of the stored props and just restore the property that was different, remembering to delete the last key of the saved properties array when the user "undid" what he had done. Undo's should go BACK in the array, not add another element IMHO. Seems doable, only how would you check to see if ANY of the properties had changed? There must be some kind of obscure message that gets sent when a property of an object is altered. 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. 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. Bob On Dec 8, 2011, at 9:03 AM, Keith Clarke 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 _______________________________________________ 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
