Thanks for the kind words, glad it actually worked too! Mike
On Mon, Oct 1, 2012 at 10:03 AM, Jim Little <littlejam...@mac.com> wrote: > Hi Mike, > > Thank you for contributing this plugin to the community. > > I've tried it out this morning and it worked flawlessly. > > I like your UI as it is … simple and intuitive. > > The code is nicely documented. > > Thanks again, > > Jim Little > > > On Sep 30, 2012, at 6:52 PM, Mike Bonner wrote: > > > Would anyone mind checking over a stack for me? I've come to the > > conclusion that I just don't have the energy for a real project (plus > with > > my design skills its pretty much out of my reach) but I do think there > are > > some useful aspects to the thing as it sits right now. Unfortunately my > > other efforts to extend it have.. er.. How to put this politely. Ok > > they've sucked. > > > > As it sits, the stack will track the mainstacks that are open, filtered > > based on a list of filters in a field. (to eliminate untitled mainstacks > > and rev stacks from the list) The list should auto update when changes > are > > made (thanks to pete, thanks pete!) > > It also maintains a list of all stacks currently backed up. The backups > are > > stored in an array in a property of the stack. > > > > What its good for: > > Want to take a snapshot of a mainstack and all of its substacks that are > in > > memory? (They don't have to be saved, and even if they are, the version > is > > memory is what will be backed up) select from the list and click backup. > > The stacks are added to the array of backed up stacks, and the plugin > > stack saves itself. > > > > If you took a snapshot of a stack hierarchy and then manage to break the > > stack you're working on, you can then recover the snapshot and look at > the > > code of the recovered copy along side the main working stack. If a stack > is > > with an identical name is already in memory the recovered stacks are > named > > "copy of thestackname" so there is no worry about the "that stack is > > already in memory" message. > > > > Want to revert to the snapshot? Just close the stacks you wish to dump, > > then either rename the "copy of.." or close the misnamed stacks and then > > recover them again. They'll pop back out with the correct name as long > as a > > stack name is not already in use. If the destroystack property is not set > > for your stacks this means forcibly removing them from memory. > > > > Thats about it. Why am I blabbing all this here? Because someone (with a > > better grasp of design and structure for this sort of thing, AKA not me) > > could easily convert the method in to a cvs. The sheer speed at which a > > stack and its substacks can be grabbed this way is amazing, So, anyone > and > > everyone is welcome to look it over, incorporate any pieces and/or parts > > into different projects, mangle it, whatever. > > > > The current version of the stack can be found at > > https://dl.dropbox.com/u/11957935/mdbRevisionPlugin.livecode The > automagic > > stack updates won't work unless the stack script is inserted into front. > > The scripts are documented, and there is a test stack "saved" as a backup > > in a property of the stack. the test stack has a field with another short > > description of how things work. > > _______________________________________________ > > 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
