Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxf.cso.uiuc.edu!lnk287
From: lnk287@uxf.cso.uiuc.edu
Newsgroups: comp.sys.mac.hypercard
Subject: Re: R/Ws to disk
Message-ID: <75900004@uxf.cso.uiuc.edu>
Date: 22 Oct 88 18:30:00 GMT
References: <20@<Oct>
Lines: 30
Nf-ID: #R:<Oct:20:uxf.cso.uiuc.edu:75900004:000:1467
Nf-From: uxf.cso.uiuc.edu!lnk287    Oct 22 13:30:00 1988


Well, your assumptions are correct in a sense, Stacy.
The normally handy feature of having HC save every change you make is causing
you all of your grief.  I don't think anybody except for Bill Atkinson and
the HyperCard team at Apple know what triggers a save to disk routine,
but it's obvious that any kind of put into a field will cause it, along
with certain other things like changing tools and userlevels.  You _can_
circumvent the constant savings with the newer 1.2 version of HyperCard,
but at a price...
 
All you need to do is protect the stack so that the user cannot modify the
stack.  This sounds awkward, and you shouldn't expect the end user to do it.
Thankfully you can set this from a script, like so:
 
set the cantmodify of this stack to true -- turn protect ON
set the cantmodify of this stack to false -- turn protect OFF
 
After doing this any kind of write into a field will still work, but the
disk file will not be updated.
 
THE CATCH:  If you jump to another card, or do anything else to the field,
            the information will most likely be lost.  You can write a
script to save the field in a temporary variable, set the cantmodify to
false, then put the information back into the field.  You might be able
to turn the protect off and still have the current information stay, I 
haven't checked to see if that would work.  In either case this will help
you out a bit, I think...
 
						Louis Koziarz
						lnk287@uxf.cso.uiuc.edu