Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!well!oster
From: oster@well.sf.ca.us (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Off Screen Bit Maps
Message-ID: <22239@well.sf.ca.us>
Date: 19 Dec 90 04:01:33 GMT
References: <1990Dec17.212129.27971@morrow.stanford.edu>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 36

In article <1990Dec17.212129.27971@morrow.stanford.edu> craig@pangea.Stanford.EDU (Craig Jarchow) writes:
_>Question: How can one use offscreen bit maps that appear and disappear during
_>a program and avoid heap fragmentation? I notice that 
_>offScreen.portBits.baseAddr must be a pointer, not a handle. Should I allocate
_>a handle anyway, and lock and dereference it when I need to draw on the
_>bit map or CopyBits() from it?

Yes, allocate it in a handle, and lock/unlock it while you are drawing/
copybitsing it. Free it the rest of the time. If you need to lock it for a long
time, 	(i.ew., while you want to do many other things) call MoveHHi()
on it before you lock it.

By the way, I've given up calling lock and unlock directly. I find my
programs are weasier to reason anbout if I say:

	SignedByte	state;
	state = HSetLockState(h);
	bits.baseAddr = *h;
	CopyBits(...
	HSetState(h, state);

where HSetLockState is my own routine, which is:
SignedByte	HSetLockState(h)Handle h;{
	SignedByte state;

	state = HGetState(h);
	HLock(h);
	return state;
}

This way, at every point, I can assume that my handles are still locked
if I locked them earlier. It is one less thing to worry about.

-- 
-- David Phillip Oster - At least the government doesn't make death worse.
-- oster@well.sf.ca.us = {backbone}!well!oster