Opening a Supercard file in Livecode?

[Peter M. Brigham, MD]

I have some scripts in an updater stack that might be generalizable. I was forced to do this because my practice management stack was too big and complex to rewrite from scratch once I realized 10y ago or so that not separating data and UI was a big mistake (the project started as a Hypercard stack). I never learned enough about database management to tackle redoing the whole thing. In fact one of the benefits of storing the data on multiple cards, one for each patient (as opposed to a database, which is what I would have done if I knew what I was doing 15-20y ago), is that I have very sophisticated search functions that work seamlessly using LC's native find command. Which would mean to revise the whole structure of the thing and preserve my find commands would *really* mean having to learn SQL or whatnot, and I already have three half-time jobs... (:-)

Anyway, as a result, I update my stacks (for the handful of other users) by keeping track of changes semi-automatically, logging them into an updater stack, then storing scripts and other properties in arrays (and also storing substacks as custom properties), and then adjusting everything on the user's machine by setting scripts and other properties and replacing substacks in a repeat loop, so the user data is preserved but the GUI is updated.

I can work on extracting and generalizing my routines in between other things in the next few weeks, if anyone is interested.

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig

On Jan 24, 2012, at 11:57 AM, Pete wrote:

> My thought is to not limit it to scripts necessarily, but all objects in a
> stack - stack, substacks, cards, controls, along with all their properties
> both standard and custom.
> 
> I see it as a standalone program that would open a stack file, grab all the
> above info and write it into a database.  There would then be an option to
> compare two versions of the same stack and present a list of everything
> that had changed between them.  I guess you could even recreate a stack
> file in an emergency.
> 
> I already have code that does a lot of the work to get all the info needed
> from a stack but currently it just presents it online and doesn't store it
> anywhere.
> 
> I'm guessing there'll be some gotchas along the way, but I think this could
> be a useful tool as part of some sort of version control system.  I can
> think of several occasions where it would have saved me a lot of time.
> 
> Pete
> 
> On Tue, Jan 24, 2012 at 7:17 AM, Richard Gaskin
> <ambassador at fourthworld.com>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<http://LiveCodejournal.com/blog.irv>
>> 
>> ______________________________**_________________
>> 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<http://lists.runrev.com/mailman/listinfo/use-livecode>
>> 
>> 
> 
> 
> -- 
> Pete
> Molly's Revenge <http://www.mollysrevenge.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