Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM doesn't unlock Handles (was: ROM unlocks Handles).
Message-ID: <9450@hoptoad.uucp>
Date: 1 Jan 90 00:51:48 GMT
References: <3875@atr-la.atr.co.jp> <4525@helios.ee.lbl.gov> <3888@atr-la.atr.co.jp> <3889@atr-la.atr.co.jp> <2632@draken.nada.kth.se> <3902@atr-la.atr.co.jp>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 51

In article <3902@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de Cheveigne)
writes:
>>  tempH = NewHandle(sizeof(WindowRecord));
>>  MoveHHi(tempH);
>>  HLock(tempH);
>>  theWindow = GetNewWindow(4711, (GrafPtr) *tempH, 0L);
>>  SetWRefCon(theWindow, tempH);
>>
>>  tempH = GetWRefCon(theWindow);
>>  CloseWindow(theWindow);
>>  DisposHandle(tempH);
>>
>>But, alas, that means you can't use the WRefCon for something else...
>
>Wow!  I always wanted to put a window record in a Handle, but never
>dared.  Do you actually sometimes unlock the Handle and let it float?

That's expressly forbidden.  Some people were doing this in their grow
zone routines before the II, and their code broke under color systems.
The auxiliary window list counts on the pointers staying the same.  I
suppose you could fix up the auxiliary window list pointers now, but
then Apple could institute yet another table that stashes window
pointers (perhaps in the Layer Manager) and you'd be SOL again.

>If you don't, I fail to see the advantage of a non-relocatable block
>at the top of the heap over one at the bottom.  

I don't understand that either.  In fact, it looks as if you're likely
to be creating big holes at the top of the heap.  I don't see why it's
better to have them at the top.

>If you do unlock, don't you risk confusing the Window Manager or
>Multifinder when the block actually moves?

Spot on, old chap.

>Using the refcon is not a big problem, because you can make it point
>to a structure (preferably relocatable) that contains a field that
>points back to your Handle, along with other fields for whatever else
>you need to associate with the window.

I don't know why your correspondent said that you can't use the window
refCon for anything else if you use it to store this handle.  First,
you don't have to store the handle at all; you can use RecoverHandle on
the window pointer to find the handle.  And as you pointed out, if you
do store it, it can be stored in a struct stored in the refCon.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

These are not my opinions, those of my ex-employers, my old schools, my
relatives, my friends, or really any rational person whatsoever.