Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!well!gurgle
From: gurgle@well.sf.ca.us (Pete Gontier)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Adding MENU generates "Unexpected error 69320382, [SORRY]"
Message-ID: <22994@well.sf.ca.us>
Date: 4 Feb 91 19:12:44 GMT
References: <1991Jan26.210319.3409@midway.uchicago.edu> <22935@well.sf.ca.us> <1991Jan30.071816.23847@midway.uchicago.edu>
Organization: cellular
Lines: 57

In article <1991Jan30.071816.23847@midway.uchicago.edu> martin@cs.uchicago.edu writes:
>I see I should have been more clear about my intentions.  I want something
>that is like MacroMaker, in that its menu is added to *every* menubar.  So
>my technique is to get the menu at INIT time and add it to the menubar via
>a patch applied before MultiFinder gets to the traps.

OK, this make a bit more sense. But in that case, I wouldn't be bothering
with a DA at all, which is what seemed to be indicated by your reference to
OpenDeskAcc.

In any case, here's how I've done it in the past:

Patch MenuSelect and DrawMenuBar. Go ahead and tail patch them. I've done it;
they're safe, and they're likely to be, forerevermore, because they're
generally only called from RAM adddresses, and you can't very well patch the
ROM by inspecting a return address that lives in RAM.

In each patch, insert your menu before calling the old address. If you have
any work to do in building your menu, do it only in the patch to MenuSelect.
DrawMenuBar only displays your menu title. If MenuSelect returns your INIT's
menu ID, you do your stuff and change the return value you pass back to the
caller of MenuSelect to 0, so it thinks nothing was selected. Then remove
your menu. It's all very zen -- you're there, and you're not there.

The catch is that you have to work out some way to support FullWrite here;
FW never calls MenuSelect. Your menu title appears as a result of your
DrawMenuBar patch, but it can't be selected. FullWrite had to implement
those PC-style walk-down menus no self-respecting Mac user would ever use,
and to do it they stopped calling MenuSelect. That's amazing to me. An
application, no less, pulling a hack stunt like that. Anyway, it can be
fixed, because QuickMail's QM Menu gets around it somehow (consult INIT
Tracker for the relevant clues -- I think it patches InsertMenu).

>I thought an InitGraf might be necessary before InitFonts, since InitFonts
>seems necessary for the GetMenu I do at INIT time.  But even so, I seem to
>get address errors in GetFontInfo depending on the phase of the moon...?

Got no idea on that one for you. I wouldn't imagine, though, that InitFonts
would be necessary for GetMenu, since GetMenu does no drawing. It might be
that A5 reference -- A5 is undocumented at INIT time. It all depends, of
course, on when you do your GetMenu. If it's during a menu trap, like
DrawMenuBar or MenuSelect, you know all the relevant managers have been
initialized.

>>Now, about this DetachResource business: why? The Menu Manager is
>>perfectly happy with a resource handle. I've never bothered to detach a
>>menu resource, and although I can't think of anything specifically wrong
>>with it offhand, I think I would err on the conservative side.
>
>Because after the INIT is done, it will close its file and I believe the
>resource will go away unless it has been detached.

You're right; I see now that you're not allocating the menu in a DA's open
message. Make sure you put it in the System heap, as well.
-- 
 Pete Gontier, gurgle@well.sf.ca.us
 Software Imagineer, Kiwi Software, Inc.