Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csmil.umich.edu
From: cash@csmil.umich.edu (Howard Cash)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Where to put window handling routines
Message-ID: <1068@mailrus.cc.umich.edu>
Date: 9 May 89 19:49:20 GMT
References: <1067@mailrus.cc.umich.edu>
Sender: usenet@mailrus.cc.umich.edu
Reply-To: cash@csmil.umich.edu (Howard Cash)
Organization: Cognitive Science and Machine Intelligence Laboratory
Lines: 80

>----- I wrote -------

> CASE 1:  The event handling struct is the first field in a bigger struct 
>	that includes window data.  A handle to the whole thing is in the 
>	window's RefCon
> CASE 2:  The handling struct includes a window pointer to the window 
> being handled. [A global list of such struct is searched for the one
> refering to the current window.  Only window DATA goes in the RefCon]

Thanks for your responses.  Both of you said that you prefered to have a 
global list carrying the window management stuff and that you would 
reserve the RefCon for window data: 
 
>----- Doug replied ---------
>  1) I prefer to avoid omnibus records that cram all the related
>  information together, but use smaller records with pointers (or
>  handles, in the mac environment).  Embedding data strucures within
>  larger ones (like the toolbox puts grafports within windowrecords
>  within dialogrecords) has always seems a bit of a kludge to me...  
>
>  2) In generic dispatch mechanisms like this I prefer to leave the
>  window refcon alone.  I use a list of structs with the window pointer
>  and some data relating to window manager functions (drag rect, size
>  rect, scrolling information).  Data that the window might manage
>  (relating to its contents) can then be kept in the refcon if that
>  seems more convenient...  
>
>  3) Event dispatching is not, in my experience, impeeded by having to
>  search the global list of these structs.  The windows are few, and
>  continuous actions (dragging the mouse) generally work by dispatching
>  the mousedown event once, then bypassing this search on each drag.
>
>  Doug Felt
>-- and Brad replied ----
>  I prefer CASE 2 because it leaves the window's RefCon free for other 
>  purposes.  Since there's only one RefCon per window, I'd rather not 
>  have my window-management routines gobble it up.  I prefer 
>  implementations that use up as few scarce resources (like the 
>  RefCon) as possible.  You never know when you're going to have a 
>  desperate need for that RefCon.
>
>  Brad Needham

My question is "What resources are you really saving?"

Assume a record structure like this:

typedef struct {      /* window management struct */
  ProcPtr keyp;          /* keydown event function */
  ProcPtr mousep;        /* mousedown event func */
  ProcPtr updatep;       /* window update func */
  ProcPtr closep;        /* data disposal func.  Call when closing */ 
  ProcPtr etc_etc_p;     
} WinMgr, **WinMgrHand;


typedef struct {      /* handle to THIS goes in window's RefCon */
  WinMgr wm;            /* embedded window management struct */
  long rest;		/* a place to put any other data */
} WinStorage;


Now the window carries with it all the info it needs to manage itself.
You still have space in the RefCon to store anything you want, you just
use the "rest" field of "WinStorage" like you would the RefCon.  (Of
course, you probably want to define macros to access the data rather 
than typing in all the indirection each time).  You still have the same
window "resources" to play with, but you eliminate the overhead of a 
global list and the time needed to search it.  I realize that the search 
time will not be long since you can only see so many windows at one time.
But there is some work to make sure that the windowStruct list stays in
sync with the windows that are actually there.

I am intentionally playing the devil's advocate in this because I want 
the most defensible solution.

Let's hear.

-howard