Bob, I think you'd have to find some way to preserve object IDs or a lot of stuff would break. Datagrids, for example, store the row template as a long id. And, as you pointed out, behaviors.
On Tue, Jan 24, 2012 at 9:43 AM, Bob Sneidar <b...@twft.com> wrote: > Actually, I think plain text would work here better, unless arrays were > stored in properties. Even then, you could save the arrays as text using > the printKeys() function. There are text comparison utilities out there > which are quite good at highlighting the differences between two plain text > files. > > I think grouped objects would have to be kept together too. Easier to put > back together later. > > This actually seems like the beginnings of a version management plugin. > The bugger in all of it is that you would have to avoid recording object > ID's, opting for the long names of everything. Also, behaviors would be > problematic. They would have to be listed without the ID's of the objects > they were set to. > > Bob > > > On Jan 24, 2012, at 7:17 AM, Richard Gaskin wrote: > > > Pete wrote: > > > >> All good points. I guess I'm thinking of a different situation that > >> multiple people working on the same project. When someone reports a bug > >> that crept into a particular version of an application, it would be > useful > >> to see what changes were made to the stack that might have introduced > the > >> bug. > > > > That's a very good point. > > > > It shouldn't be too hard to write a tool that can examine two sets of > stack files and produce a list of handlers which have been modified. > > > > It would be a little tricky to write because we can't currently have two > stacks open with the same name, but I think it may be doable using > something like this: > > > > The tool would create an array with object references as the primary key > and handler names as the secondary key, where the value is the handler > definition itself. > > > > Then after it completes a scan of a given stack, it then goes through > the other version and compares the same handler definitions, noting > changes, missing items, and new items, and produces a clickable list of > changes that could take the developer to the script in question. > > > > I'll add this to my "To Do" list; seems like it would be useful..... > > > > -- > > Richard Gaskin > > Fourth World > > LiveCode training and consulting: http://www.fourthworld.com > > Webzine for LiveCode developers: http://www.LiveCodeJournal.com > > LiveCode Journal blog: http://LiveCodejournal.com/blog.irv > > > > _______________________________________________ > > 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
