marsella@porthos.rutgers.edu (Stacy Marsella) (10/21/88)
I was doing a simple experiment in Hypercard and came upon the following problem... Hypercard is doing disk I/O at inopportune moments. Specifically, when a script writes to a field (eg by use of a put command), hypercard will do some disk I/O. This disk I/O tends to screw up the mouse button handling, even to the degree of missing clicks. I thought it might be due to hypercard calling in special fonts, but it happens even with the default font/size/style. My suspicion at this time is that hypercard is updating stack information. I have tried different size ram caches to no avail. I have set userlevel to 2, which appears to reduce the frequency of I/O but not nearly enough. On the other hand, manual typing into a field does not generate these disk operations. (also, using the hypertalk TYPE command doesn't cause the disk operation but it does cause me other problems..) It would be a big help if someone could give me a more exact explanation as to what is happening or an idea on how to convince hypercard to defer the disk I/O??? Thanks, stacy marsella marsella@aramis.rutgers.edu
lnk287@uxf.cso.uiuc.edu (10/23/88)
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.edudan@Apple.COM (Dan Allen) (11/01/88)
In article <Oct.20.15.02.47.1988.15102@porthos.rutgers.edu> marsella@porthos.rutgers.edu (Stacy Marsella) writes: >It would be a big help if someone could give me a more exact >explanation as to what is happening or an idea on how to convince >hypercard to defer the disk I/O??? During HyperCard's idle time it cleans up RAM writing it to disk until the state of the stack on the disk exactly mirrors the state of the stack in RAM. HyperCard does this so that if the power went out you will not lose any work. At worst you would only lose a very small amount of work. In short, you CANNOT DEFER THE DISK I/O. Dan Allen Software Explorer
cosmo-rt@cosmo.UUCP (CosmoNet / Herr Tress) (02/11/89)
sss Sorry this is a test only. merrychristmas