The Window Manager, which, amongst other things, provides functions for managing windows, itself depends on QuickDraw. QuickDraw supports drawing into colour graphics ports, which are individual and complete drawing environments with independent coordinate systems. Each window represents a colour graphics port.

Your application typically creates document windows, which allow the user to enter and display text, graphics, or other information. A document window is a view into the document. If the document is larger than the window, the window is a view of a portion of the document.

Window Basics

• Title Bar. The bar at the top of a window that displays the window's name, contains the close, zoom, and collapse boxes, and indicates whether a window is active. You usually display a newly created window with the title "untitled". When the user opens a saved document, you assign the document's filename to the window in which it is displayed.

• Close Box. Offers the user a quick way to close a window. The close box is sometimes called the go-away box.

• Full, Vertical, and Horizontal Zoom Boxes. Offer the user a quick way to choose between two different window sizes, one established by the user and one by the application.

• Collapse Box. Lets the user collapse and uncollapse a window.

• Size Box. Lets the user change the size of a window.

• Draggable Area. That part of the window's frame less the title bar.

Scroll bars, which allow the user to view different parts of a document containing more information than can be displayed on the screen at the one time, are not part of a window's structure and must be separately created and managed. By convention, scroll bars are placed on the right and lower edges of those windows which require them.

Active and Inactive Windows

When the user activates one of your application's windows, the Window Manager redraws the window's title bar and frame, the close box, the title text, the zoom box, the collapse box, and the size box. Your application must reinstate the appearance of the rest of the window to its state prior to the deactivation, activating any controls (scroll bars, etc.), drawing the scroll box in the same position, restoring the insertion point, and highlighting the previous selection, etc.

When a window belonging to your application becomes inactive, the Window Manager redraws the title bar and frame as shown at Fig 1, hiding the close, zoom, collapse, and size boxes. Your application must deactivate any controls, remove highlighting from selections, and so on.

When the user clicks in an inactive document window, your application should make the window active but should not make any selections in response to the click. To make a selection, the user should be required to click again. This behaviour protects the user from unintentionally losing an existing selection when activating the window.

Types of Appearance-Compliant Windows

• Document types.

• Dialog and alert types.

• Utility window types (sometimes referred to as floating window types).

Dialog and Alert Types

Utility (Floating) Window Types

Window Definition IDs

• Window Definition Function. The system software and various Window Manager functions call a window's window definition function (WDEF) when they need to perform certain window-related actions, such as drawing or re-sizing a window's frame. The definition function draws the window's frame, draws the close, zoom, collapse, and size boxes (if any), draws the window title (if any), determines which region the cursor is in within the window, calculates the window's content and structure regions (see below), and performs any special initialisation or disposal tasks.

• Variation Code. A single WDEF can support up to 16 different window types. The WDEF defines a variation code, an integer from 0 to 15, for each window type it supports.

The window definition ID is derived by multiplying the resource ID of the WDEF by 16 and adding the variation code to the result, as is shown in the following:

Window Type Usage

Window Types For Modal Alert Boxes and Modal Dialog Boxes. Modal alert boxes and modal dialog boxes are merely special-purpose windows that require no window manipulation elements. Modal alert boxes generally use the window type kWindowAlertProc and modal dialog boxes generally use window type kWindowModalDialogProc; however, kWindowPlainDialogProc and kWindowShadowDialogProc may also be used.

Window Types For Movable Modal Alert Boxes and Movable Modal Dialog Boxes. Movable modal alert boxes and movable modal dialog boxes are used when you want the user to be able to move the alert or dialog window or to bring another application to the foreground before the dialog is dismissed. Movable modal alert boxes use the window type kWindowMovableAlertProc and movable modal dialog boxes use the window type kWindowMovableModalDialogProc.

Window Types For Modeless Dialog Boxes. Modeless dialog boxes allow the user to perform other tasks within the application without first dismissing the dialog box. User interface guidelines require that the kWindowDocumentProc window type, which can be moved or closed but not resized or zoomed, be used for modeless dialog boxes.

The creation and handling of alert and dialog boxes is addressed in detail at Chapter 8- Dialogs and Alerts.

Window Regions

A region is an arbitrary area, or set of areas, on the QuickDraw coordinate plane. The outline of a region is one or more closed loops. Regions are explained in more detail at Chapter 12 - Drawing With QuickDraw.

Handles to these regions, which are represented by constants of type RegionWindowCode, may be obtained via a call to GetWindowRegion. The definitions of these regions, and the constants which represent them, are as follows:

Other Regions

• The Update Region. The update region is a dynamic region which accumulates all areas of a window's content region which need updating (that is, re-drawing).

• The Gray Region. The entire area of the desktop, that is, the screen area that is not occupied by the menu bar, is known as the gray region. The Window Manager maintains a pointer to the gray region in a low-memory global variable named GrayRgn. You can retrieve a handle to the gray region with the function LMGetGrayRgn.

All controls included in a window "belong" to that individual window and are displayed within the colour graphics port which represents that window. For each window your application creates, the Window Manager creates a control list, a series of entries pointing to the descriptions of controls associated with a window.

The Window List

The location of a window on the screen is defined in global coordinates, that is, coordinates which reflect the entire potential drawing space. QuickDraw recognises a coordinate plane whose origin is the upper left corner of the main screen, whose positive x-axis extends rightward and whose positive y-axis extends downward (see Fig 8). In QuickDraw functions, the horizontal offset is ordinarily labelled h, and the vertical offset v. The coordinate plane is bounded by the limits of QuickDraw coordinates, which range from -32768 to 32,767.

When QuickDraw creates a new colour graphics port (usually, when you create a new window), it defines a bounding rectangle for the port in global coordinates. Ordinarily, the bounding rectangle represents the entire area of the screen on which the window appears. The bounding rectangle is stored in the colour graphics port data structure, in the bounds field of a structure called a pixel map in Color QuickDraw.

The colour graphics port data structure also includes a field called portRect, which defines the rectangle to be used for drawing. In a colour graphics port representing a window, the portRect rectangle represents the window's content region. Within the port rectangle, the drawing area is described in local coordinates. Fig 8 illustrates the local and global coordinate systems for a window which is 100 pixels high by 200 pixels wide, and which is placed with its content region 70 pixels down and 60 pixels to the right of the upper left corner of the screen.

The colour graphics port is addressed in detail at Chapter 11 - QuickDraw Preliminaries.

When the Window Manager creates a window, it places the origin of the local coordinate system at the upper-left corner of the window's port rectangle. Note, however, that the Event Manager describes mouse events in global coordinates, and that you must do most of your window manipulation in global coordinates.

Colour Window Structure

     struct CWindowRecord
     {
       CGrafPort    port;          // Window's colour graphics port.
       short        windowKind;    // Class of window.
       Boolean      visible;       // true if window is visible.
       Boolean      hilited;       // true if window is highlighted.
       Boolean      goAwayFlag;    // true if window has close box.
       Boolean      spareFlag;     // true if window has zoom box.
       RgnHandle    strucRgn;      // Handle to structure region.
       RgnHandle    contRgn;       // Handle to content region.
       RgnHandle    updateRgn;     // Handle to update region.
       Handle       windowDefProc; // Handle to window definition function.
       Handle       dataHandle;    // Handle to window state data structure.
       StringHandle titleHandle;   // Handle to window's title.
       short        titleWidth;    // Title width in pixels.
       ControlRef   controlList;   // Handle to window's control list.
       CWindowPeek  nextWindow;    // Pointer to next window structure in window list.
       PicHandle    windowPic;     // Handle to an optional picture.
       long         refCon;        // Reference constant.
     };
     typedef struct CWindowRecord CWindowRecord;
     typedef CWindowRecord *CWindowPeek;

It is important to note that the colour graphics port is the first field of the colour window structure and that the data type CWindowPtr is defined as a pointer to the colour graphics port, not to the colour window structure. Fields in the colour window structure are accessed using CWindowPeek, which is a pointer to a colour window structure. (CWindowPeek is rarely used, however, since you usually do not need to access or directly modify fields in a colour window structure. The Window Manager automatically updates the colour window structure when you make changes to a window, and supplies functions for changing and reading some fields of the colour window structure.)

The close box region, drag region, zoom box region, collapse box region, and size box region are not included in the colour window structure. The WDEF determines the location of those particular regions.

Compatibility

One of the more basic functions of the Window Manager is to report where the cursor is when the application receives a mouse-down event. As was also stated at Chapter 2, the Window Manager function FindWindow tells your application whether the cursor is in a window and, if it is in a window, in exactly which window and which part of that window. FindWindow is thus used as a first filter for mouse-down events, separating events which merely affect the window display from events which manipulate data.

Creating Your Application's Windows

The following describes the main fields of the 'WIND' resource:

Positioning Specification

Creating a 'WIND' Resource Using Resorcerer

Creating the Window From the 'WIND' Resource

You can allow GetNewCWindow to itself allocate memory for your colour window structure; however, memory fragmentation effects will be minimised by allocating the memory yourself from a non-relocatable block allocated for such purposes during your application's initialisation function, and then passing the pointer to GetNewCWindow.

Adding Scroll Bars

• If you are creating a window because the user is creating a new document, you can display the window immediately by calling ShowWindow. (This change in visibility adds to the update region and triggers an update event. Your application should respond to the update event by calling its own function for drawing the content region.)

• If you are creating a new window to display a saved document, you should retrieve the user's data before displaying the window.

The positioning constants previously described allow you to position new windows automatically. When used, those positioning constants concerned with staggering new window placement will ensure that the Window Manager will use any vacated position for the next new window.

Positioning a Saved Document Window on the DeskTop

Some explanation of user state and standard state is necessary. The user state is the last size and location the user, through sizing and dragging actions, established for a window. The standard state is the size and location that your application determines is the most convenient size for the window. For windows with full zoom boxes, this typically the gray area of the screen minus three pixels all round.

The user and standard states are stored in the state data structure, whose handle is assigned to the dataHandle field of the colour window structure:

     struct WStateData 
     {
       Rect userState;   // Size and location established by user.
       Rect stdState;    // Size and location established by application.
     };
     typedef struct WStateData WStateData;
     typedef WStateData *WStateDataPtr, **WStateDataHandle;

     typedef struct 
     {
       Rect    userStateRect; // User state rectangle.
       Boolean zoomState;     // Window state: true = standard, false = user.
     } windowState;
     typedef windowState *windowStatePtr;
     typedef windowStatePtr *windowStateHdl;

The demonstration program MoreResources.c at Chapter 17 - More on Resources shows how to save the window state to the resource fork of a document file.

Drawing a Window's Contents

As stated at Chapter 2 - Low-Level and Operating System Events, if the window contains a static display such as a picture, you can let the Window Manager take care of updating the content region by assigning a handle to the picture in the windowPic field of the colour window structure.

Managing Multiple Windows

You can use different strategies for keeping track of windows, including different kinds of windows. As previously stated, the refCon field in the colour window structure is set aside specifically for use by applications and can be used to store different kinds of data, such as a number representing a window type or a handle to a structure containing data relating to window management.

As an example, the refCon field could hold a number representing the type of dialog box or, in the case of document windows, a handle to an application-defined document structure. The document structure might typically hold a handle to the text being edited, handles to the scroll bars, a file reference number and a file system specification for the document's file, plus a flag indicating whether data has changed since the last save, as shown in this example application-defined document structure:

     typedef struct 
     {
       TEHandle       editRec;
       ControlHandle  vScrollBar;
       Controlhandle  hScrollbar;
       short          fileRefNum;
       FSSpec         fileFSSpec;
       boolean        windowDirty;
     } docStructure;
     typedef docStructure *docStructurePtr;
     typedef docStructurePtr *docStructureHdl;

Note that, if the active window is a modal or movable modal alert or dialog box, no action is required by your application. Modal and movable modal alert and dialog boxes are handled by the ModalDialog function, which does not pass the event to your application.

Handling Keyboard Events

When you receive a key-down event, you should first check whether the user is holding down a modifier key and another key at the same time. Your application should respond to key-down events by inserting data into the document, changing the display or taking other appropriate actions. Typically, your application provides feedback for standard keystrokes by drawing the character on the screen.

Handling Update Events

When your application receives an update event, it should redraw the content area. When your application redraws the content area, the Window Manager ensures that it does not accidentally draw into other windows by clipping all screen drawing to the visible region of the window's colour graphics port. The visible region is that part of a colour graphics port that is actually visible on screen, that is, the part that is not covered by other windows. The Window Manager stores a handle to the visible region in the visRgn field of the colour graphics port structure.

Before redrawing the content area, your application should call BeginUpdate and, when it has completed the drawing, it should call EndUpdate. As shown at Fig 11, BeginUpdate temporarily adjusts the visible region to equate to the intersection of the visible region and the update region. Because QuickDraw limits its drawing to this temporarily modified visible region, only those parts of the window which actually need updating are drawn. BeginUpdate also clears the update region, thus ensuring that the Event Manager does not continue sending an endless stream of update events.

When the drawing is completed, and as shown at Fig 11, EndUpdate restores the visible region of the colour graphics port to the full visible region.

The reason for these update region/visible region machinations is that the handle to the update region is stored in the window structure's updateRgn field while the handle to the visible region is stored in the colour graphics port structure's visRgn field. QuickDraw knows the colour graphics port structure intimately, but knows nothing about the window structure or its updateRgn field. QuickDraw needs something it can work with, hence the above process whereby the visible region is temporarily made the equivalent of the update region while QuickDraw does its drawing.

Manipulating the Update Region

Your application typically triggers activate events itself by calling SelectWindow following a mouse-down event. SelectWindow brings the selected window to the front, removes highlighting from the previously selected window and adds highlighting to the selected window. It then generates two activate events, the first to tell your application to deactivate the previously active window and the second to activate the newly activated window.

When your application receives the event for the window about to be made inactive, it should hide the controls and remove any highlighting of selections. When your application receives the event for the newly activated window, it should draw the controls and restore the content area as necessary, adding the insertion point in its former location or highlighting previously highlighted sections as appropriate.

The application-defined function for handling activate events should typically first determine whether the window being activated/deactivated is a document window or a modeless dialog box. It should then perform the appropriate activation/deactivation actions. The function does not need to check for modal alert or modal dialog boxes because the Dialog Manager's ModalDialog function automatically handles activate events for those windows.

Manipulating Windows

• The user state is the window size and location established by the user. If your application does not supply an initial user state, the user state is simply the size and location of the window when it was created, until the user resizes it.

• The standard state is the window size and location that your application considers most convenient. Typically, this might be the screen gray area minus three pixels all round. In a word-processing program, however, a standard state window might show a full page, if possible, or a page of full width and as much length as will fit on the screen. If the user changes the page size using the print Style dialog box, the application might adjust the standard state to reflect the new page size.

• If your application does not define a standard state, the Window Manager will automatically set it to the entire gray region of the main screen minus a three-pixel border on all sides. The user cannot change a window's standard state.

• The user and standard states are stored in a structure whose handle appears in the dataHandle field of the colour window structure. The Window Manager sets the initial values of the userState and stdState fields when it fills in the window structure and it updates the userState whenever the user resizes the window.

When FindWindow returns either inZoomIn or inZoomOut, your application should call TrackBox to handle highlighting of the zoom box and to determine whether the cursor is inside or outside the zoom box when the button is released. If TrackBox returns true, your application should call ZoomWindow to resize the window, following which it should redraw the content region.

Windows With Vertical or Horizontal Zoom Boxes

Your application should ensure that, when a vertical zoom box is clicked, only the vertical size of the associated window changes. Similarly, when a horizontal zoom box is clicked, your application should ensure that only the horizontal size of the associated window changes.

Re-Sizing a Window

To avoid unmanageably large or small windows, you supply upper and lower size limits when you call GrowWindow. The sizeRect parameter of GrowWindow specifies the upper and lower size limits in a single structure of type Rect. Note that the values in the structure represent window dimensions, not screen coordinates:

• sizeRect.top represents the minimum vertical measurement.

• sizeRect.left represents the minimum horizontal measurement.

• sizeRect.bottom represents the maximum vertical measurement.

• sizeRect.right represents the maximum horizontal measurement.

When the user releases the mouse button, GrowWindow returns a long integer which describes the window's new height (in the high-order word) and width (in the low-order word). A value of zero indicates that the window size did not change. When GrowWindow returns a value other than zero, you call SizeWindow to resize the window.

When the mouse-button is released and GrowWindow returns a non-zero value, the application-defined function for re-sizing windows should call SizeWindow to draw the window in its new size. The scroll bars and window contents should then be adjusted to the new size.

Closing a Window

When the user clicks in the close box, TrackGoAway should be called to track the mouse until the user releases the mouse button. If TrackGoAway returns true, meaning that the user did not release the mouse button outside the close box, your application should invoke its function for closing down the window.

The specific steps you take when closing a window depend on what kind of information the window contains and whether the contents need to be saved. The application-defined function should cater for different types of windows, that is, modeless dialog boxes (which may be merely hidden with HideWindow rather than closed completely) and standard document windows. In the latter case, the function should check whether any changes have been made to the document since it was opened and, if so, provide the user with an opportunity to save the document to a file before closing the window. (This whole process is explained in detail at Chapter 16 - Files.)

DisposeWindow and CloseWindow

CloseWindow removes a window from the screen, removes it from the window list, and discards its data storage except for the window structure. CloseWindow should be used when you have allocated storage for the window structure manually, that is, if you created a nonrelocatable block for the window structure and passed the pointer as the wStorage parameter in the NewCWindow or GetNewCWindow call. In this case, the nonrelocatable block containing the window structure must be disposed of separately.

Hiding and Showing a Window

ShowWindow will make the window visible and SelectWindow will make it the active window.

Providing Help Balloons

How you choose to provide help balloons for the content area depends mainly on whether your windows are static or dynamic. A static window does not change its title or reposition any of the objects within its content area. A dynamic window can reposition any of it objects within its content area, or its title may change. For example, any window that scrolls past areas of interest to the user is a dynamic window because the object with associated help balloons can change location as the user scrolls. The following addresses the case of static windows only.

Help balloons for static document and utility windows are defined in 'hrct' and 'hwin' resources.

Creating 'hrct' and 'hwin' Resources Using Resorcerer

The 'hwin' (window help) resource is used to associate the help balloons defined in an 'hrct' resource with a particular window. All 'hrct' resources must have resource IDs equal to or greater than 128. Fig 13 shows an 'hwin' resource being created using Resorcerer.

Main Window Manager Constants, Data Types and Functions

• The constants, data types, and functions introduced with Mac OS 8 and the Appearance Manager are shown in blue.

• Those older constants, data types and functions affected by the introduction of Mac OS 8 and the Appearance Manager, but which may still be used in certain circumstances, are shown in red.

kWindowDocumentProc                = 1024  // Document windows
kWindowGrowDocumentProc            = 1025
kWindowVertZoomDocumentProc        = 1026
kWindowVertZoomGrowDocumentProc    = 1027
kWindowHorizZoomDocumentProc       = 1028
kWindowHorizZoomGrowDocumentProc   = 1029
kWindowFullZoomDocumentProc        = 1030
kWindowFullZoomGrowDocumentProc    = 1031
kWindowPlainDialogProc             = 1040  // Dialogs and Alerts
kWindowShadowDialogProc            = 1041
kWindowModalDialogProc             = 1042
kWindowMovableModalDialogProc      = 1043
kWindowAlertProc                   = 1044
kWindowMovableAlertProc            = 1045
kWindowFloatProc                   = 1057  // Utility (floating) windows
kWindowFloatGrowProc               = 1059
kWindowFloatVertZoomProc           = 1061
kWindowFloatVertZoomGrowProc       = 1063
kWindowFloatHorizZoomProc          = 1065
kWindowFloatHorizZoomGrowProc      = 1067
kWindowFloatFullZoomProc           = 1069
kWindowFloatFullZoomGrowProc       = 1071
kWindowFloatSideProc               = 1073
kWindowFloatSideGrowProc           = 1075
kWindowFloatSideVertZoomProc       = 1077
kWindowFloatSideVertZoomGrowProc   = 1079
kWindowFloatSideHorizZoomProc      = 1081
kWindowFloatSideHorizZoomGrowProc  = 1083
kWindowFloatSideFullZoomProc       = 1085
kWindowFloatSideFullZoomGrowProc   = 1087

kDialogWindowKind       = 2
kApplicationWindowKind  = 8

inDesk        = 0
inNoWindow    = 0
inMenuBar     = 1
inSysWindow   = 2
inContent     = 3
inDrag        = 4
inGrow        = 5
inGoAway      = 6
inZoomIn      = 7
inZoomOut     = 8
inCollapseBox = 11

kWindowTitleBarRgn     = 0
kWindowTitleTextRgn    = 1
kWindowCloseBoxRgn     = 2
kWindowZoomBoxRgn      = 3
kWindowDragRgn         = 5
kWindowGrowRgn         = 6
kWindowCollapseBoxRgn  = 7
kWindowStructureRgn    = 32
kWindowContentRgn      = 33

struct CWindowRecord
{
  CGrafPort     port;           // Window's colour graphics port.
  short         windowKind;     // Class of window.
  Boolean       visible;        // true if window is visible.
  Boolean       hilited;        // true if window is highlighted.
  Boolean       goAwayFlag;     // true if window has close box.
  Boolean       spareFlag;      // true if window has zoom box.
  RgnHandle     strucRgn;       // Handle to structure region.
  RgnHandle     contRgn;        // Handle to content region.
  RgnHandle     updateRgn;      // Handle to update region.
  Handle        windowDefProc;  // Handle to window definition function.
  Handle        dataHandle;     // Handle to window state data structure.
  StringHandle  titleHandle;    // Handle to window's title.
  short         titleWidth;     // Title width in pixels.
  ControlRef    controlList;    // Handle to window's control list.
  CWindowPeek   nextWindow;     // Pointer to next window structure in window list.
  PicHandle     windowPic;      // Handle to an optional picture.
  long          refCon;         // Reference constant.
};
typedef struct CWindowRecord CWindowRecord;
typedef CWindowRecord *CWindowPeek;

struct WStateData
{
  Rect  userState;  // User state.
  Rect  stdState;   // Standard state.
};
typedef struct WStateData WStateData;
typedef WStateData *WStateDataPtr, **WStateDataHandle;

void  InitWindows(void);

WindowPtr  GetNewCWindow(short windowID,void *wStorage,WindowPtr behind);
WindowPtr  NewCWindow(void *wStorage,const Rect *boundsRect,ConstStr255Param title,
           Boolean visible,short procID,WindowPtr behind,Boolean goAwayFlag,long refCon);

void  GetWTitle(WindowPtr theWindow,Str255 title);
void  SetWTitle(WindowPtr theWindow,ConstStr255Param title);

void  DrawGrowIcon(WindowPtr theWindow);
void  SelectWindow(WindowPtr theWindow);
void  ShowWindow(WindowPtr theWindow);
void  HideWindow(WindowPtr theWindow);
void  ShowHide(WindowPtr theWindow,Boolean showFlag);
void  HiliteWindow(WindowPtr theWindow,Boolean fHilite);
void  BringToFront(WindowPtr theWindow);
void  SendBehind(WindowPtr theWindow,WindowPtr behindWindow);

short      FindWindow(Point thePoint,WindowPtr *theWindow);
WindowPtr  FrontWindow(void);

void  MoveWindow(WindowPtr theWindow,short hGlobal,short vGlobal,Boolean front);
void  DragWindow(WindowPtr theWindow,Point startPt,const Rect *boundsRect);
long  DragGrayRgn(RgnHandle theRgn,Point startPt,const Rect *boundsRect,
      const Rect *slopRect,short axis,DragGrayRgnProcPtr actionProc);

void  SizeWindow(WindowPtr theWindow,short w,short h,Boolean fUpdate);
long  GrowWindow(WindowPtr theWindow,Point startPt,const Rect *bBox);

Boolean  TrackBox(WindowPtr theWindow,Point thePt,short partCode);
void     ZoomWindow(WindowPtr theWindow,short partCode,Boolean front);

Boolean  TrackGoAway(WindowPtr theWindow,Point thePt);
void     CloseWindow(WindowPtr theWindow);
void     DisposeWindow(WindowPtr theWindow);

void  BeginUpdate(WindowPtr theWindow);
void  EndUpdate(WindowPtr theWindow);
void  InvalRect(const Rect *badRect);
void  InvalRgn(RgnHandle badRgn);
void  ValidRect(const Rect *goodRect);
void  ValidRgn(RgnHandle goodRgn);

void       SetWindowPic(WindowPtr theWindow,PicHandle pic);
PicHandle  GetWindowPic(WindowPtr theWindow);
long       GetWRefCon(WindowPtr theWindow);
void       SetWRefCon(WindowPtr theWindow,long data);
short      GetWVariant(WindowPtr theWindow);

OSStatus  GetWindowRegion(WindowPtr inWindow,WindowRegionCode inRegionCode,
          RgnHandle ioWinRgn)

Boolean   IsWindowCollapsable(WindowPtr inWindow);
Boolean   IsWindowCollapsed(WindowPtr inWindow);
OSStatus  CollapseWindow(WindowPtr inWindow,Boolean inCollapseIt);
OSStatus  CollapseAllWindows(Boolean inCollapseEm); 

void       SetDeskCPat(PixPatHandle deskPixPat);
void       GetWMgrPort(GrafPtr *wPort);
void       GetCWMgrPort(CGrafPtr *wMgrCPort);
RgnHandle  LMGetGrayRgn(void);