cash@csmil.umich.edu (Howard Cash) (05/09/89)
've been looking through some C code for the Mac, and I've noticed two fundamentally different philosophies on the management of window events. I want some votes on the prefered methodology. Both cases use a struct of function pointers that handle various events in the window (keyboard, mousedown, update, etc). 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 so an event in the window looks in the RefCon for the appropriate handling function. The RefCon ends up pointing to a fairly bulky structure, but you always know where to find relevant functions or data. CASE 2: The handling struct includes a window pointer to the window being handled. A list of such structs is maintained. When the event arises, the list is searched for a "Window Handler" struct whose windowPtr field is the same as the window where the event occurred. This takes some search time, but the RefCon is free to carry only window-specific DATA and theJ management functions are isolated elsewhere. How do all you experienced mac programmers deal with this issue? Howard Cash cash@csmil.umich.edu This posting contains no opinions.
cash@csmil.umich.edu (Howard Cash) (05/10/89)
>----- 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