Volume Number: 14 (1998)
Issue Number: 4
Column Tag: Getting Started

Having a Dialog with Your Mac

by Dave Mark

Programming the Dialog Manager

In last month's column, we explored the inner workings of the Menu Manager. This month, we'll build on that experience and create a program with menus, windows, and, for the first time, dialogs and alerts. This program is the biggest one we've tackled so far, so this months column is a bit longer than usual.

We'll start off just as we did in last month's column, by creating our MBAR and MENU resources. Create a folder inside your Development folder named "Dialogger Folder." Next, launch ResEdit and create a new file called Dialogger.rsrc inside this new folder.

Now select Create New Resource from the Resource menu and create a new MBAR resource according to the specifications in Figure 1. As you can see, our program will feature three different menus.

Figure 1. Specifications for Dialogger's MBAR resource.

Close the MBAR and MBAR picker windows and again select Create New Resource from the Resource menu. Create a MENU resource according to the specifications in Figure 2. This MENU represents the Apple menu. Be sure that the MENU's resource id is 128.

Figure 2. Specifications for the Apple MENU resource.

Now create another MENU resource according to the specifications shown in Figure 3. This MENU represents the File menu. Be sure the MENU's resource id is set to 129.

Figure 3. Specifications for the File MENU resource.

Now create one final MENU resource according to the specifications shown in Figure 4. This MENU represents the Edit menu. Be sure this MENU's resource id is set to 130.

Figure 4. Specifications for the Edit MENU resource.

OK. Close up your MENU and MENU picker windows. This next part might be a little tricky. You'll need three PICT images, one of a dog, one of an elephant, and one of a squirrel. If you don't have any of these handy, drop into your favorite graphics program and do the best you can. If you're really stuck, just create pictures with the words Afghan, Elephant, and Squirrel in them. Paste all three pictures into your scrapbook.

Back in ResEdit, Paste the pictures into three PICT resources. Use Figure 5 as your guide. Be sure your afghan is PICT 128, your elephant is PICT 129, and that your squirrel is PICT 130.

Figure 5. Three PICT resources. Note which resource id goes with which PICT.

Actually, you can use any PICT images that strike your fancy. Once you understand what this program does and how it works, feel free to customize it to your own desires.

Close the PICT picker window. Once again, select Create New Resource from the Resource menu. This time, create a DLOG resource. A miniature version of your desktop will appear with a window somewhere in the middle. Depending on the size of your monitor, your DLOG window may appear somewhat scaled. When the DLOG editor appears, customize it according to the specifications in Figure 6.

Figure 6. Specifications for the DLOG resource.

Be sure that you click the dialog window type (8th from the left) at the top of the editing window. Also, be sure you uncheck the Initially visible and Close box check boxes on the right side of the window. This resource controls the appearance of a dialog box's window. Now we'll create a resource that defines the items that appear in this DLOG.

Double-click the DLOG window (not the editing window, but the window that appears in the middle of the editing window, on the mini-desktop) and a DITL editing window will appear. At the same time, a DITL item palette will appear (Figure 7). This palette contains a list of all the items you can add to your dialog.

Figure 7. The DITL item palette.

When you start constructing a DITL (Dialog ITem List), you always start with the OK and Cancel buttons. The OK button is always item number one, and the Cancel button (if it exists) is always item number two. As you'll learn, these item numbers have special significance to the Dialog Manager. Click the Button palette, dragging to the left, on to your DITL window. The outline of a button will appear (Figure 8).

Figure 8. Dragging a button from the palette window.

When you release the mouse button, a new button item will appear. Double click this button item and a specifications window will appear. Fill it in according to the specs shown in Figure 9. Notice that the Enabled check box is checked. This tells the Dialog Manager to respond to this item when it is clicked on in a dialog box. If the item were not enabled, clicks in it would be ignored.

Figure 9. Specifications for DITL item #1.

Close the spec window and drag a second button from the palette. Double-click it and enter the specs shown in Figure 10. Close the specs window.

Figure 10. Specifications for DITL item #2.

This time, drag a Radio Button fromthe palette. Double-click it and make it reflect the specs shown in Figure 11. Close the specs window.

Figure 11. Specifications for DITL item #3.

Drag a second Radio Button from the palette and make it reflect the specs shown in Figure 12.

Figure 12. Specifications for DITL item #4.

Drag a third Radio Button from the palette and make it reflect the specs shown in Figure 13.

Figure 13. Specifications for DITL item #5.

Next, drag a Static Text item from the palette and make it reflect the specs in Figure 14. Notice that the Enabled check box is unchecked. Normally, user clicks in static text are ignored.

Figure 14. Specifications for DITL item #6.

Next, drag a Check Box item from the palette and make it reflect the specs in Figure 15.

Figure 15. Specifications for DITL item #7.

Finally, drag a User Item from the palette and make it reflect the specs in Figure 16. As was the case with Static Text, notice that the Enabled check box is unchecked. A User Item just acts as a marking rectangle. We'll use it as a guide for drawing a picture, later in the program. There may be times when you want your User Items enabled. For now leave it as is.

Figure 16. Specifications for DITL item #8.

When you close your last item spec window, your DITL editing window should look like the one shown in Figure 17. If it doesn't, go back and check out your specs. If you need to make changes, you can use the tools in the DITL menu, such as Show Item Numbers, Set Item Number..., and Renumber Items....

Figure 17. The completed DITL resource.

OK, we're almost done. Close the DITL and DLOG windows till you're back down to your main window. You might want to save at this point. I'll wait... Select Create New Resource from the Resource menu and create an ALRT resource. The ALRT editor looks just like the DLOG editor. It should. Alerts are basically simplified dialogs, easier to use and easier to build. (Top: 40, Left: 40, Bottom: 145, Right: 350)

Select Get Resource Info from the Resource menu and change the ALRT's resource id to 129. Next, close the Info window and change the DITL ID: field in the ALRT window to 129. We have to create a DITL for the items in the alert and, since we've already got a DITL 128, we'll use 129 for the alert.

In general, it's a good idea to keep the ALRT and DLOG resource ids in sync with their respective DITL resource ids. Our DLOG 128 goes with DITL 128 and ALRT 129 goes with DITL 129.

Double-click the ALRT window inside the mini-desktop. A new DITL resource will appear. You'll add two items to the DITL. First, create a Button according to the specs in Figure 18.

Figure 18. Specifications for the alert's OK button.

Next, create a Static Text item item according to the specs in Figure 19. Be sure the Enabled check box is unchecked.

Figure 19. Specifications for DITL item #2.

Whew! That's it. Quit ResEdit, being sure to save your changes. Let's get to the project.

Launch CodeWarrior and create a new project based on the MacOS:C/C++:Basic Toolbox 68k stationary. Turn off the Create Folder check box. Name the project Dialogger.mcp and place it in your Dialogger folder. Remove SillyBalls.c and SillyBalls.rsrc from the project; we will not be using these files. From the Finder, drag and drop your Dialogger.rsrc file into the project window. You also can remove the ANSI Libraries group from the project, because we won't need them, either.

Select New from the File menu to create a new window. Save it under the name Dialogger.c, Select Add Window from the Project menu to add Dialogger.c to the project. Your project window should look something like Figure 20.

Figure 20. Dialogger project window.

Rather than print the code here twice, we'll go straight to the walk-through. You can type in the code as we discuss it below and you will end up with the complete program, or you can save your fingers some effort and get the complete project from MacTech's ftp site ftp://ftp.mactech.com/src/mactech/volume14_1998/14.04.sit.

Much of the Dialogger source code will look familiar to you from earlier programs. I'll keep the chatter to a minimum. You've seen some of these constants before. The rest I'll explain as we get to them. One convention you should be aware of is the 'i' convention. Just as we did with menu items, constants that reflect a dialog item start with the letter 'i'.

#include <Controls.h>
#include <Dialogs.h>
#include <Menus.h>
#include <Quickdraw.h>
#include <Sound.h>

#define kBaseResID      128
#define kAboutALRTid    129
#define kDialogResID    128

#define kVisible        true
#define kMoveToFront    (WindowPtr)-1L
#define kNoGoAway       false
#define kSleep          7L

#define kFirstRadio     3

#define kOn             1
#define kOff            0

Each time you add an item to a dialog item list, the item is given a unique number. The OK button always gets number 1 and the Cancel button always gets number 2. ResEdit's DITL menu (which appears when you edit a DITL) allows you to renumber the items in a DITL, as well as turn the display of item numbers on and off. In general, it's a good idea to write down (or print out) each of your DITL item id's once you finish your ResEdit session and you start writing your code. I usually create the item #defines for my MENU and DITL resources right away so I won't forget them.

#define iAfghan          3
#define iElephant        4
#define iSquirrel        5

#define iShowPreview     7
#define iUserItem        8

#define kLeftMargin      5
#define kTopMargin       40

#define mApple           kBaseResID
#define iAbout           1

#define mFile            kBaseResID+1
#define iSettings        1
#define iQuit            3

Dialogger makes use of three globals. gDone is set to true when the program is ready to exit. gShowPreview corresponds to the Show preview checkbox in the Settings dialog. It is set to true whenever the check box is checked. We could avoid the use of a global by using the same initial setting for Show preview each time we enter the routine that handles the dialog box. By using a global, however, the setting of the check box survives, even after the dialog is dismissed.

/************** Globals *************/
Boolean    gDone, gShowPreview = true;

The same thinking holds true for gCurrentPICT. This global tells us which picture we're currently looking at, ensuring that the dialog's Show preview brings up the current picture of my pet Fred.

short      gCurrentPICT = kBaseResID;

As always, here's a complete list of function prototypes.

/************** Functions *************/
void    ToolBoxInit( void );
PicHandle  LoadPICT( short picID );
void    CreateWindow( void );
void    MenuBarInit( void );
void    EventLoop( void );
void    DoEvent( EventRecord *eventPtr );
void    HandleMouseDown( EventRecord *eventPtr );
void    HandleMenuChoice( long menuChoice );
void    HandleAppleChoice( short item );
void    HandleFileChoice( short item );
void    DoUpdate( EventRecord *eventPtr );
void    DoDialog( void );
void    FlipControl( ControlHandle control );
void    DrawPreview( DialogPtr dialog, short picID );
void    SwitchPICT( void );

The following two routines are part of System 7, and won't work with earlier versions of the operating system.

main() initializes the Toolbox, then sets up the menu bar and creates the My Pet Fred window. Once that's done, the main event loop is entered.

/******************************** main *********/

void  main( void )
{
  ToolBoxInit();
  MenuBarInit();
  
  CreateWindow();
  
  EventLoop();
}

Nothing new here...

/*********************************** ToolBoxInit */
void  ToolBoxInit( void )
{
  InitGraf( &qd.thePort );
  InitFonts();
  InitWindows();
  InitMenus();
  TEInit();
  InitDialogs( NULL );
  InitCursor();
}

LoadPICT() uses GetPicture() to load a PICT resource. If the PICT can't be found, beep once, then exit.

/******************************** LoadPICT *********/
PicHandle  LoadPICT( short picID )
{
  PicHandle  pic;
  
  pic = GetPicture( picID );
  
  if ( pic == NULL )
  {
    SysBeep( 10 );  /* Couldn't load the PICT resource!!! */
    ExitToShell();
  }
  return pic;
}

CreateWindow() loads the current PICT, then uses the Rect that defines its border to define the size of a new window. The idea here is to create a window exactly big enough to hold the entire PICT. Of course, this wouldn't be a good idea if the PICT was bigger than the entire screen. Hmmm... Is this an idea for a column on scroll bars? We'll see...

/******************************** CreateWindow *********/
void  CreateWindow( void )
{
  WindowPtr  window;
  PicHandle  pic;
  Rect        r;
  
  pic = LoadPICT( gCurrentPICT );
  
  r = (**pic).picFrame;

We really don't care where on the screen the PICT is, we just care about its size. We'll use OffsetRect() to normalize the Rect, moving it so it's the size of the PICT, but so its upper-left corner is at the point (kLeftMargin, kTopMargin).

  OffsetRect(&r, kLeftMargin - r.left, kTopMargin - r.top);

Next, we use NewWindow() to create a new window. We could have used GetNewWindow() but we'd have to change the window's size. Whatever floats your boat...

  window = NewWindow( NULL, &r, "\pMy Pet Fred", kVisible,
      noGrowDocProc, kMoveToFront, kNoGoAway, 0L );

If the window couldn't be created, beep once, then exit.

  if ( window == NULL )
  {
    SysBeep( 10 );  /* Couldn't load the WIND resource!!! */
    ExitToShell();
  }

Since we created the window as kVisible, this call to ShowWindow() is reduntant. I prefer to leave it in, so it's very obvious when I revisit the code at 3 in the morning.

  ShowWindow( window );
  SetPort( window );
}

MenuBarInit() does the usual, loading the MBAR resource, adding the apple items to the menu, then drawing the menu bar.

/****************** MenuBarInit ***********************/
void  MenuBarInit( void )
{
  Handle        menuBar;
  MenuHandle    menu;
  
  menuBar = GetNewMBar( kBaseResID );
  SetMenuBar( menuBar );

  menu = GetMenuHandle( mApple );
  AppendResMenu( menu, 'DRVR' );
  DrawMenuBar();
}

EventLoop() and DoEvent() should be familiar to you. No big changes.

/******************************** EventLoop *********/
void  EventLoop( void )
{    
  EventRecord    event;
  gDone = false;
  while ( gDone == false )
  {
    if ( WaitNextEvent( everyEvent, &event, kSleep, NULL ) )
      DoEvent( &event );
  }
}

/************************************* DoEvent   */
void  DoEvent( EventRecord *eventPtr )
{
  char    theChar;
  switch ( eventPtr->what )
  {
    case mouseDown: 
      HandleMouseDown( eventPtr );
      break;
    case keyDown:
    case autoKey:
      theChar = eventPtr->message & charCodeMask;
      if ( (eventPtr->modifiers & cmdKey) != 0 ) 
        HandleMenuChoice( MenuKey( theChar ) );
      break;
    case updateEvt:
      DoUpdate( eventPtr );
      break;
  }
}

As you've seen in other programs, HandleMouseDown() processes the latest mouseDown event.

/************************************* HandleMouseDown */
void  HandleMouseDown( EventRecord *eventPtr )
{
  WindowPtr  window;
  short      thePart;
  long        menuChoice;

FindWindow() tells you which window, and which part of the window, the mouseDown occurred in.

  thePart = FindWindow( eventPtr->where, &window );

Depending on the part of the window the mouseDown occurred in, the event is handled accordingly.

  switch ( thePart )
  {
    case inMenuBar:
      menuChoice = MenuSelect( eventPtr->where );
      HandleMenuChoice( menuChoice );
      break;
    case inSysWindow : 
      SystemClick( eventPtr, window );
      break;
    case inContent:
      SelectWindow( window );
      break;
    case inDrag : 
      DragWindow( window, eventPtr->where, 
        &qd.screenBits.bounds );
      break;
  }
}

HandleMenuChoice() handles menu selections from either the Apple or File menus.

/****************** HandleMenuChoice ********************/
void  HandleMenuChoice( long menuChoice )
{
  short  menu;
  short  item;
  
  if ( menuChoice != 0 )
  {
    menu = HiWord( menuChoice );
    item = LoWord( menuChoice );
    
    switch ( menu )
    {
      case mApple:
        HandleAppleChoice( item );
        break;
      case mFile:
        HandleFileChoice( item );
        break;
    }
    HiliteMenu( 0 );
  }
}

HandleAppleChoice() is the same as in previous programs.

/****************** HandleAppleChoice *******************/
void  HandleAppleChoice( short item )
{
  MenuHandle  appleMenu;
  Str255      accName;
  short      accNumber;
  
  switch ( item )
  {
    case iAbout:
      NoteAlert( kAboutALRTid, NULL );
      break;
    default:
      appleMenu = GetMenuHandle( mApple );
      GetMenuItemText( appleMenu, item, accName );
      accNumber = OpenDeskAcc( accName );
      break;
  }
}

HandleFileChoice() starts off by declaring a totally useless (and unused) variable. Feel free to delete this line of code. I don't know what I was thinking!

/****************** HandleFileChoice ********************/
void  HandleFileChoice( short item )
{
  short  newPICTid;

If Settings was selected, call DoDialog() to put up the dialog box. If Quit was selected, set gDone to true which will cause the program to drop out of the main event loop.

  switch ( item )
  {
    case iSettings:
      DoDialog();
      break;
    case iQuit:
      gDone = true;
      break;
  }
}

DoUpdate() gets called whenever the Window Manager generates an updateEvt, asking Dialogger to redraw the contents of the My Pet Fred window.

/********************************** DoUpdate   */
void  DoUpdate( EventRecord *eventPtr )
{
  PicHandle  pic;
  WindowPtr  window;
  Rect        r;

The WindowPtr is embedded in the event's message field. We'll need this in a bit.

  window = (WindowPtr)eventPtr->message;

Since the window was created the exact size of the current picture, we'll load the PICT, make window the current port, then draw the PICT in the window.

  pic = LoadPICT( gCurrentPICT );
  
  SetPort( window );
  
  BeginUpdate( window );
  
  r = window->portRect;
  DrawPicture( pic, &r );
  
  EndUpdate( window );
}

DoDialog() is where the real action is.

/************************************* DoDialog   */
void  DoDialog( void )
{
  DialogPtr    dialog;
  Boolean      dialogDone = false;
  short        itemHit, itemType;
  Handle        itemHandle;
  Rect          itemRect;
  short        curRadioButton;

GetNewDialog() loads a DLOG resource (as well as its associated DITL resource) with the id specified in the first parameter. The second parameter allows you to designate a filter function that will get called repeatedly as events occur inside your dialog. (We won't use this filter function here. Maybe in a future column). The third parameter determines whether the dialog's window appears in front of all other windows, just like the corresponding parameter in GetNewWindow().

  dialog = GetNewDialog( kDialogResID, NULL, kMoveToFront );

Just as you would with a window, make the dialog visible and make it the current port. As you'll see, DialogPtrs and WindowPtrs are quite similar and DialogPtrs can be passed to the same routines you'd normally pass a WindowPtr to.

  ShowWindow( dialog );
  SetPort( dialog );

SetDialogDefaultItem() tells the Dialog Manager which button is the default button (normally the OK button). The default button is the button you'd like activated when the user hits the return key or presses enter. The Dialog Manager will make sure to draw a bold outline around the default button, making it easy for the user to see.

  SetDialogDefaultItem( dialog, ok );

SetDialogCancelItem() performs a similar function, allowing you to specify the button that gets activated when the user types (normally the Cancel button). ok and cancel are predefined in a #include file to be 1 and 2 respectively.

  SetDialogCancelItem( dialog, cancel );

This next calculation tells us which of our three radio buttons should be turned on. Radio buttons always travel in sets. Just like the channel selector buttons on your car radio, one button is always selected, and the others always off. When a radio button is selected its circle is filled in, like the Elephant radio button in Figure 21.

Figure 21. A set of radio buttons.

  curRadioButton = gCurrentPICT - kBaseResID + kFirstRadio;

GetDialogItem() uses a dialog item's id to retrieve its type, a handle to it, and its bounding Rect. We'll cast the retrieved handle to a ControlHandle, then use the Control Manager routine SetControlValue() to set the value of the radio button control to kOn. As you can see, radio buttons have two legal values, on (1) and off (0). All controls have a limited range of values. Buttons, radio buttons, check boxes, and scroll bars are all examples of controls.

  GetDialogItem( dialog, curRadioButton, &itemType, 
    &itemHandle, &itemRect );
  SetControlValue( (ControlHandle)itemHandle, kOn );

If the Show preview check box is supposed to be checked, we'll use GetDialogItem() and SetControlValue() to turn it on. By default, all dialog item controls are off.

  if ( gShowPreview )
  {
    GetDialogItem( dialog, iShowPreview, &itemType, 
      &itemHandle, &itemRect );
    SetControlValue( (ControlHandle)itemHandle, kOn );
  }

Our last step in preparing our dialog box is to call our own DrawPreview() function. DrawPreview() checks to see if the Show preview check box is checked. If so, it will draw the miniature picture of My Pet Fred. Otherwise, DrawPreview() will erase any existing preview, then exit.

  DrawPreview( dialog, curRadioButton + 
    kBaseResID - kFirstRadio );

OK. Now our setup work is done. We've set our controls to their initial values, and performed any necessary drawing. This is typical of dialog management. Now we'll enter the dialog loop, which will bring our dialog to life. The dialog loop keeps going until we set dialogDone to true. We'll do this when either the Cancel or OK buttons is pressed.

  while ( ! dialogDone )
  {

King of all Dialog Manager routines, ModalDialog() grabs an event from the event queue, calls the filter function (if you've specified one), then processes the event. ModalDialog() sets itemHit to the item clicked (if the event was a mouseDown).

    ModalDialog( NULL, &itemHit );

Now all you have to do is figure out what to do with itemHit.

    switch( itemHit )
    {

If the click was in the OK or Cancel buttons, set dialogDone to true.

      case ok:
      case cancel:
        dialogDone = true;
        break;

If the click was in the Show preview check box, we'll flip the value of the check box (turn it on if off, off if it was on) then call DrawPreview() to redraw the preview area accordingly.

      case iShowPreview:
        GetDialogItem( dialog, iShowPreview, &itemType,
          &itemHandle, &itemRect );
        FlipControl( (ControlHandle)itemHandle );
        
        DrawPreview( dialog, curRadioButton + 
          kBaseResID - kFirstRadio );
        break;

If one of the radio buttons was clicked, we first check to make sure it wasn't the lit one. If the lit one was clicked, there's no reason to do anything.

      case iAfghan:
      case iElephant:
      case iSquirrel:
        if ( curRadioButton != itemHit )
        {

If a new one was clicked, turn off the current button, then turn on the new one. Always turn off the old button before you turn on the new one. That way you won't ever have two radio buttons lit at the same time. This can be jarring to the user.

          GetDialogItem( dialog, curRadioButton, &itemType,
            &itemHandle, &itemRect );
          FlipControl( (ControlHandle)itemHandle );
          
          GetDialogItem( dialog, itemHit, &itemType,
            &itemHandle, &itemRect );
          FlipControl( (ControlHandle)itemHandle );

Next, make curRadioButton reflect the new current radio button, then redraw the preview.

          curRadioButton = itemHit;
          
          DrawPreview( dialog, curRadioButton + 
            kBaseResID - kFirstRadio );
        }
        break;
    }
  }

Once we drop out of the main dialog loop, we'll make the dialog window invisible. Even though it's invisible, we'll still have access to its controls, so we can change some things then make it visible again if we want.

  HideWindow( dialog );

If the dialog was dismissed with a click in Cancel, we don't care about any changes made since the dialog was opened. If the click was in OK (if the user pressed return or enter the Dialog Manager is nice enough to simulate the appropriate click for us), we'll save the current value of the Show preview check box in gShowPreview.

  if ( itemHit == ok )
  {
    GetDialogItem( dialog, iShowPreview, &itemType,
      &itemHandle, &itemRect );
    if ( GetControlValue( (ControlHandle)itemHandle ) 
    == kOn )
      gShowPreview = true;
    else
      gShowPreview = false;

Next, if the state of the radio buttons has changed, we'll call the routine SwitchPICT() to switch the My Pet Fred window to reflect our new choice for a domestic destructive device.

    if ( gCurrentPICT != curRadioButton +
        kBaseResID - kFirstRadio )
    {
      gCurrentPICT = curRadioButton +
        kBaseResID - kFirstRadio;
      SwitchPICT();
    }
  }

Either way, once we're done, we call DisposeDialog() to free up all memory allocated for the dialog. If we hadn't made the dialog invisible first, this would have done that for us.

  DisposeDialog( dialog );
}

FlipControl() calls GetControlValue() to retrieve the current value of the control, then uses '!' and SetControlValue() to flip its value.

/****************************** FlipControl   */
void  FlipControl( ControlHandle control )
{
  SetControlValue( control, ! GetControlValue( control ) );
}

DrawPreview() first checks to see if the Show preview check box is off.

/****************************** DrawPreview  */
void  DrawPreview( DialogPtr dialog, short picID )
{
  PicHandle  pic;
  short      itemType;
  Handle      itemHandle;
  Rect        itemRect;

  GetDialogItem( dialog, iShowPreview, &itemType, 
    &itemHandle, &itemRect );
  if ( GetControlValue( (ControlHandle)itemHandle ) == kOff )
  {

If so, the preview area is erased and DrawPreview() returns.

    GetDialogItem( dialog, iUserItem, &itemType, 
      &itemHandle, &itemRect );
    EraseRect( &itemRect );
    return;
  }

If the check box is checked, the current picture is drawn in the rectangle specified by the user item. As you can see, the user item comes in handy for marking a rectangle in your dialog box. If you want to move the preview area, just go into ResEdit and drag it around or resize it and your changes are reflected next time you run your program.

  pic = LoadPICT( picID );
  
  GetDialogItem( dialog, iUserItem, &itemType, 
    &itemHandle, &itemRect );
  FrameRect( &itemRect );
  
  InsetRect( &itemRect, 1, 1 );
  DrawPicture( pic, &itemRect );
}

SwitchPICT() deletes the front window, then creates a new window. Since CreateWindow() uses the current picture to determine the size and contents of its window, the newly selected pet Fred candidate will appear.

/******************************* SwitchPICT   */
void  SwitchPICT( void )
{
  WindowPtr  window;
  
  window = FrontWindow();
  DisposeWindow( window );
  
  CreateWindow();
}

Save your source code and you're ready to roll. When you run the project, a window should appear, just big enough to hold PICT 128. If you made your PICTs too small, go back and fix them. Figure 22 shows my window.

Figure 22. My Pet Fred.

Go to the File menu and select Settings (Figure 23). Play with all the dialog items. Change some things, then select Cancel, verifying that things stay the same the next time you go into the dialog box. Uncheck the Show preview check box to see what happens. Play, play, play!

Figure 23. The Settings dialog box.

Wow, these columns are getting long! That's the price we pay as we dive deeper into the Toolbox, I guess. Well, I'll see you next month. Till then, read the Dialog and Control Manager chapters in Inside Macintosh: Macintosh Toolbox Essentials.