Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Message-ID: <7610@hoptoad.uucp>
Date: 9 Jun 89 19:38:43 GMT
References: <50967@tut.cis.ohio-state.edu> <7547@hoptoad.uucp> <4972@umd5.umd.edu> <51276@tut.cis.ohio-state.edu> <2015@husc6.harvard.edu> <1241@speedy.mcnc.org> <2024@husc6.harvard.edu> <13855@dartvax.Dartmouth.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 28

In article <13855@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu
(Earle R. Horton) writes:
>Aesthetically, however, it's a real bad
>idea.  It produces the same problem that you get using ToolScratch,
>ApplScratch, or any other lowmem location--conflicts with other pieces
>of code.

Unless, as I pointed out when I proposed it, you save the old state and
restore it before anyone else gets a chance to use it.  If you save the
value, call Standard File, extract the value stashed by your filter
procs, and restore the old value, there's no way any code that would
use the scratch storage will be interfered with.  Only system software,
interrupt driven code, and trap patches would have a chance to see it,
and it's clear that such software is not allowed to use the scratch
areas.

Like storing the information in the refCon of the DA window, using
ApplScratch or ToolScratch with a state save/restore seems to have been
a useful and *easy* technique that was dismissed out of hand for some
unknown reason.  It's stuff like this that makes me wonder why I put so
much work into this newsgroup.  It's frustrating.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934

"I slept with Faith, and found a corpse in my arms on awaking; I drank and
 danced all night with Doubt, and found her a virgin in the morning."
    -- Aleister Crowley, THE BOOK OF LIES