Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!draken!d88-jwa
From: d88-jwa@nada.kth.se (Jon Watte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM doesn't unlock Handles (was: ROM unlocks Handles). LONG
Message-ID: <2632@draken.nada.kth.se>
Date: 27 Dec 89 22:30:22 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>
Reply-To: d88-jwa@nada.kth.se (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 36

In article <3889@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de Cheveigne) writes:
>By this reasoning, WindowPtrs should have been Handles, since the user 
>can open and close them in any order.  

Well, for "historical reasons" they aren't...

A good thing to do is to

...
  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...
It DOES avoid cluttering the heap, though. If you don't intend to
close the window, you may ignore putting the handle into the WRefCon.

>The choice between Handle and Pointer in a program depends on the
>program's overall structure, and the kind of user interaction you wish
>to allow.  If you can get away with Pointers, then by all means do.

Pointers should be allocated before anything else, or at least when
all handles are unlocked. And they DO fragment the heap too often to
be very popular with me.

-- 
   ---  Stay alert !  -  Trust no one !  -  Keep your laser handy !  ---
             h+@nada.kth.se  ==  h+@proxxi.se  ==  Jon Watte
                    longer .sig available on request