Aug 98 Getting Started
Volume Number: 14
Issue Number: 8
Column Tag: Getting Started
by Dave Mark and Dan Parks Sydow
How a Mac program handles multiple types of windows
Back in February we covered window-related events. In that column's WindowMaster
program you saw how an application that displays a single window handles the opening,
dragging, resizing, updating, and closing of that window. Those basic window-handling
techniques are important because they're used in just about every Mac program --
but they don't go far enough. A real-world Macintosh application usually allows for
more than one window to be open at any given time. Not only that, such a program often
allows more than one type of window to be open at a time. For instance, a drawing
application might open a single window that serves as a tool palette, and then allow any
number of drawing windows to also open. When such a program is running, and one of
the windows needs updating, how does the program know what to draw in the window
that's in need of servicing? Last month's PictLister example program presented a
solution that worked for simple programs. This month we'll hold off on moving to an
entirely new topic so that we can dig deeper into just how a Mac program works with
windows. In this column we'll alter the PictLister code to come up with a solution that
works for both simple and complex programs.
Window Management Using Global Variables
When a window-related event occurs (such as a mouse click in a window's close box),
the system keeps track of the affected window. When a program calls
WaitNextEvent(), the system supplies the program with a WindowPtr that references
this window. Last month's program PictLister opened two windows -- a list window
and a picture window -- and kept track of each using a global window pointer variable.
When the system returned a WindowPtr to PictLister, the program compared it to it's
global variables to see which window was in need of handling. Since PictLister allowed
only two windows to be open, this technique was easy to implement. The simple
scenario presented in PictLister is representative of some programs (a game, for
instance, might display only a control window and a playing-area window). But many
more applications are more complex. If a program defined a half dozen window types,
and allowed any number of each to be open, you can see how difficult it would be to
define a global WindowPtr variable for each, and then keep track of which windows
were open throughout the running of the program. Obviously, for some applications a
more sophisticated window-handling technique is called for.
Window Management Using Piggybacking
The WindowRecord data type is used to hold the information that defines a window.
When a window is created from a WIND resource, that resource's information is read
from disk and stored in some of the fields of a WindowRecord in memory. The first
field of a WindowRecord is port, a graphics port (type GrafPort) that specifies the
drawing environment of a window. The WindowPtr data type is used to provide a
pointer to this first field of a WindowRecord. While your work with variables of type
WindowPtr has probably lulled you into thinking of a WindowPtr variable as a pointer
to a window, it is in fact simply a reference to only the drawing environment of a
window. To access the other fields of a window's WindowRecord you use a variable of
the WindowPeek data type. Like a variable of type WindowPtr, a variable of type
WindowPeek points to the first field of a WindowRecord. Unlike the WindowPtr,
though, a WindowPeek allows access to the other WindowRecord fields. Figure 1
illustrates this (for simplicity many of the fields of the WindowRecord have been