ADVERTISEMENT

A Rebuttal to "The Computer Knows" Article

By Tim Swihart, Co-Author "Programming for System 7"

Just a couple of notes on the August issue (which arrived in my mailbox this weekend, so hopefully not too many other have yet mentioned some of this stuff).

• First off, great issue, v2.0 looks better with each new issue. Gar's column was great tounge-in-cheek fun!

• Secondly, a quick rebuttal to a portion of one of the articles in the August '92 issue. The problem is in John Love's “The Compiler Knows” article. The problem is on page 30, left hand column. John hard codes the menu ID for the item he appended to the help menu (#define myItem 3). That's very bad! Inside Mac, Volume VI, page 11-63 says, "In the future, Apple may choose to add other items to the Help menu. To determine the number of items in the Help menu, call the CountMItems function, which is described in the Menu Manager chapter of Volume 1."

In English, that translates to, "Don't hard code the ID of the item you append to the Help menu because the actual ID will change if Apple ever adds items to, or removes items from, the Help menu. Instead, let the toolbox tell you what ID was assigned to your item - since your item will always be at the end of the menu, CountMItems gives you the ID of the appended item."

This is a simple example of why existing applications break when new operating system features are added. In this case, doing it right is simple, so there's no reason to not do it right.

Also, John's code doesn't show what to do if your app added multiple items in the Help menu. How do you figure out which is which? "Programming for System 7" (Gary Little and Tim Swihart, Addison Wesley) shows how to handle it cleanly in Listing 8-5 (page 289). To paraphrase that approach (error checking and type declarations have been removed to simplify this explanation):

/* 1 */

HMGetHelpMenuHandle(&myHelpMenuHndl);
    bottomHelpItem = CountMItems(myHelpMenuHndl);
    secondHelpItem = bottomHelpItem - 1;
    thirdHelpItem = bottomHelpItem - 2;
    if (pickedItem == bottomHelpItem) {
        // code to do what you want when last item picked
    } else {
        if (pickedItem == secondHelpItem) {
 

         // code to execute when second to last item picked
        } else {
            if (pickedItem == thirdHelpItem) {
                // code for third to last item being picked
            }
        }
    }

One last point to make while on the subject of the Help menu. There are third-party inits available that remove the Help menu (freeing up that tiny bit of menubar space it occupies). But, some of them can have unexpected side effects on applications that assume they'll have a Help Menu since the Help Manager is present (which normally seems like a relatively valid assumption). Checking for errors returned by HMGetHelpMenuHandle() isn't enough. You'll also need to verify that the returned handle isn't nil if you want truly bulletproof code. Here's how I handle this in "BNDL Banger Pro":

/* 2 */

/* The following routine is responsible for appending  */
/* application-specific help items to the 'Help' menu. */
/* It's called from "Initialize()", just before        */       
/* "DrawMenuBar()" is called.                          */
void DoAddHMItems(void)
{
   MenuHandle  myHelpMenuHndl;
   OSErr   myErr;

   myErr = HMGetHelpMenuHandle(&myHelpMenuHndl);
   if ((!myErr) && (myHelpMenuHndl != nil)) {
 // check for nil in case some has removed the help menu 
     // (stop snickering,  I'm serious - there are such 
     // hacks readily available now )
   AppendMenu(myHelpMenuHndl,
   (ConstStr255Param)"\pBNDL Banger Pro Instructions");
   }
}

• Shifting gears considerably, I'd like to offer one last suggestion. Include the phone number for the MouseHole BBS in the MouseHole report section. [Right now, the Mousehole is on hiatus. Larry Nedry is the middle of a move to Texas. So for now, we can’t be of help here. - Ed.]

Thanks for listening.