Legacy Document

Inside Macintosh: Macintosh Toolbox Essentials /

Chapter 4 - Window Manager / Using the Window Manager

Managing Multiple Windows

Your application is likely to have multiple windows on the desktop at once: one or more document windows, possibly one or more dialog boxes, and possibly some special-
purpose windows of your own. Only one window is active at a time, however.

When your application receives an event, it responds according to what kind of window is currently active and where the event occurred. When it receives a mouse-down event in the content region of an active document window, your application follows its own conventions: inserting text, making a selection, or adding graphics, for example. When it receives a mouse-down event in the menu bar, your application enables and disables menu items as appropriate--which again depends on what kind of window is active and what is selected in that window. If the user has the insertion point in an editable text field in a modal dialog box, for example, the only menu item available might be Paste in the Edit menu--and then only if there is something in the scrap to be pasted.

You can use various strategies for keeping track of different kinds of windows. The refCon field in the window record is set aside specifically for use by applications.
You can use the refCon field to store different kinds of data, such as a number that represents a window type or a handle to a record that describes the window.

The sample code in this chapter--excerpts from the SurfWriter application used throughout this book--uses a hybrid strategy:

• For document windows, the refCon field holds a handle to a document record.
• For modeless or movable modal dialog boxes, the refCon field holds a number that represents a type of dialog box.

You may well find other approaches more practical.

The SurfWriter application stores document information about the user's data, the window display, and the file, if any, associated with the data in a document record. The document record takes this form:

TYPE MyDocRec = 
   RECORD
      editRec:       TEHandle;      {handle to text being edited}
      vScrollBar:    ControlHandle; {control handle to the }
                                    { vertical scroll bars}
      hScrollBar:    ControlHandle; {control handle to the }
                                    { horizontal scroll bars}
      fileRefNum:    Integer;       {reference number for file}
      fileFSSpec:    FSSpec;        {FSSpec record for file}
      windowDirty:   Boolean;       {whether data has changed }
                                    { since last save}
   END;
   MyDocRecPtr       = ^MyDocRec;
   MyDocRecHnd       = ^MyDocRecPtr;

The SurfWriter application creates a document record every time it creates a document window, and it stores a handle to the document record in the refCon field of the window record. (See the chapter "Introduction to File Management" in Inside Macintosh: Files for a more complete illustration of how to use document records.)

When SurfWriter creates a modeless dialog box or a movable modal dialog box, it stores a constant that represents that dialog box (that is, it specifies the constant in the dialog resource, and the Window Manager sets the refCon field to that value when it creates the window record). For example, a refCon value of 20 might specify a modeless dialog box that accepts input for the Find command, and a value of 21 might specify a modeless dialog box that accepts input for the spelling checker.

When SurfWriter receives notification of an event in one of its windows, it first determines the function of the window and then dispatches the event as appropriate. Listing 4-1 illustrates an application-defined routine MyGetWindowType that determines the window's type.

Note

The MyGetWindowType function determines the type of a window from among a set of application-defined window types, which reflect the different kinds of windows the application creates. These window types are different from the standard window types defined by the definition functions, which determine how windows look and behave. To find out which one of the standard window types a window is, call the Window Manager function GetWVariant.

The sample code later in this chapter calls the MyGetWindowType function as part of its event-handling procedure, described in the section "Handling Events in Windows" beginning on page 4-36.

Listing 4-1 Determining the window type

FUNCTION MyGetWindowType (thisWindow: WindowPtr): Integer;
VAR
   myWindowType:  Integer;
BEGIN
  IF thisWindow <> NIL THEN
  BEGIN
    myWindowType := WindowPeek(thisWindow)^.windowKind;
    IF myWindowType < 0 THEN                 {window belongs to }
      MyGetWindowType := kDAWindow           { a desk accessory}
    ELSE
      IF myWindowType = userKind THEN        {document window}
        MyGetWindowType := kMyDocWindow
      ELSE                                   {dialog window}
         MyGetWindowType := GetWRefCon(window);    {get dialog ID}
  END
  ELSE
   MyGetWindowType := kNil;
END;

Notice that MyGetWindowType checks whether the window belongs to a desk accessory. This step ensures compatibility with older versions of system software. When your application is running in System 7, it should receive events only for its own windows and for windows belonging to desk accessories that were launched in its partition. See Inside Macintosh: Memory for information about partitions and Inside Macintosh: Processes for information about launching applications and desk accessories.