Thanks Bill,

> I can't speak for Andy, but I know why _I_ would have done it. There's a 
> little book called "Human Interface Guidelines". I don't have it in front 
> of me, so I can't give the exact quote, but basically it boils down to 
> "Thou Shalt Not Erase The Scrap (or do anything else) Without Being Told 
> To, Or At Least Telling The User You're Doing It".
> 
> In C, you have to deliberately _keep_ the scrap (transfer it from the 
> system scrap to the application scrap) on application launch. With ZBasic 
> being intended in part for use by programming "amateurs", it's only 
> logical to do all the "default" stuff _as_ a default; that's why you 
> don't have to call InitQuickDraw, InitText, MaxApplZone, InitThis, 
> InitThat at the start of every program - it's done for you.
> 
> In _certain_ cases, it makes sense to clear the application scrap rather 
> than loading it from the system scrap; very tight memory situations are 
> obviously one of them. (Although I'd suggest checking to see if it's so 
> big that it's a problem first...) But if I copied some text from another 
> application, then launched an FB application into which I intended to 
> _paste_ that text, and it wouldn't let me, I'd be one upset customer!

Perhaps in my panic I have not made myself entirely clear. It is not my
intent to dispose of the scrap without the user's knowledge. The scrap
is not the problem. My problem is/was that the standard FB init attempts
to load the scrap and doesn't seem to handle the situation failure
correctly and I want to bypass this problem. Bypassing this does *not*
destroy the scrap contents. As it stands, if my memory partition is not
large enough to hold the contents of the scrap, FB throws up a dialog
and then after the user attempts to dismiss it, the entire system
freezes. And now the user has lost much more than just the scrap.

I question the necessity of FB handling these routines, since, to the
best of my knowledge, the os already handles all of the necessary scap
tranfers. Well, let me look it up just to be sure.

Okay, from, "More Machintosh Toolbox", Chapter 2, Scrap Manager, page
2-12 -- 2-14:

"The system software allocates space in each application's heap for the
scrap and allocates a handle to reference the scrap... If the scrap is
too large to fit in the applications' application heap, the system
software copies the scrap to the disk and sets the value of the handle
to NIL to indicate that the scrap is on disk. The scrap manager keeps
track of whether the scrap is  in memory or on disk... ...your
application seldom needs to know the location of the scrap."

Now questions do arise about available disk space, and looking thru this
chapter very quickly, I don't see any mention of it, but I would
*assume* that the system has made provisions for this. But the bottom
line is that the system is already handling everything.

I'll be perfectly honest in telling you that I did *not* know that the
system actually attempted to load the scrap into my heap. I thought it
was all maintained in the system heap/clipboard file. But the system
approach is fine since it first checks to see if I have enough memory to
actually hold the scrap, and if not writes it out. The *favor* that FB
is doing for me (which I now believe must be addressing a problem which
is no longer a concern), wipes me out and it needs to be looked into by
Chris/David/Andy/someone. 

Maybe most of you have not encoutered this problem, but I will append
that statement with the word "yet" . The clipboard can export an amount
equal to one-half of the available memory. Lots of Mac users have lots
of memory. Lots of Mac users work in applications capable of generating
large clipboard exports. Why risk it? And I'm happy to have found a
simple work-around since I *do* value FB. It has been a very dependable
DE for me for many, many years.

DL