Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!agate!ragu!lippin
From: lippin@ragu.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac
Subject: Re: Quickergraf bugs...
Message-ID: <7786@agate.BERKELEY.EDU>
Date: 18 Mar 88 05:27:44 GMT
References: <293STORKEL@RICE> <779@trwcsed.trwrb.UUCP> <2411@coherent.com>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: lippin@ragu.UUCP (Tom Lippincott, ..ucbvax!bosco!lippin)
Organization: SOWHAT -- Stop Oppression Without Hardly Any Trouble
Lines: 28

Recently dplatt@coherent.com (Dave Platt) said:
>Apple has apparently changed the MDEF so that it can recover gracefully
>if it can't get a pixmap big enough to save the screen pixels;  it
>simply displays the menu without saving the pixels, and [when the user
>releases the mouse button or moves to a different menu] erases the menu
>rectangle to black and tells QuickDraw to invalidate the rectangle;
>the application(s) that have windows intersecting the invalidated
>rectangle are given window-update events, and can then redraw the
>erased data.

This causes a problem for me.  Since there are so many ways for
out-of-memory problems to screw up the toolbox, I've responded by
writing a growzone function which, when it can't scrounge memory, will
unload most segments, put up an alert, and then longjmp back into the
main event loop.  But this makes some menu choices fail even when
MenuSelect could get by without the memory.

What I want is a way to tell if a memory request is vital or not.  I
can write this into my side of the code, but I know of no way to test
this when it's a toolbox call that needs the memory.  Is there one?
Will there be one eventually?  (This is all grungy stuff that would be
better handled by the OS anyway, I say.)

					--Tom Lippincott
					..ucbvax!bosco!lippin

	"Those who understand will require no further explanation."
					--Saul Bellow,
					_Henderson the Rain King_