gurgle@well.sf.ca.us (Pete Gontier) (01/30/91)
In article <1991Jan26.210319.3409@midway.uchicago.edu> martin@cs.uchicago.edu writes: >For some reason Hypercard (also Microsoft Word) doesn't like the MENU >that I'm adding from my INIT/DRVR: > >The INIT that does an OpenDeskAcc. In the open routine of the DRVR, I >do (abbreviated): > > PEA -4(A5) > _InitGraf > InitFonts; > GetMenu > DetachResource Whoa there! You don't need to do an _InitGraf in a DA! And if you do find a reason to do it, certainly don't do it relative to A5, because you're likely to trash your host application's QuickDraw. If you really need to do it (and you probably don't), make sure you have your own space for QuickDraw globals and send THAT to _InitGraf. 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. Finally, re: MS Word and HyperCard, good luck. They've always been notorious as rule breakers. >I head patch DrawMenuBar: > DeleteMenu > InsertMenu > JMP <old DrawMenuBar> >Etc. This succesfully adds the MENU to the menubar and selecting from >it seems to correctly enter the Control of the DRVR. At least with >TeachText; HyperCard dies with the interesting ALRT box: > Unexpected error 69320382 [SORRY] >Microsoft Word just dies with an odd address error. >Is this a brain-damaged way to add the menu to every menubar? What's >happening? All help appreciated. Charles, IMHO, don't be patchin' traps from DA's. DA's are ugly enough at this late stage of the game without trap patches. But, to address your question, use the activate event that the Desk Manager sends you to decide when to insert and delete your menu. Much safer, and has the advantage of being documented practice. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
martin@cs.uchicago.edu (01/30/91)
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. In article <22935@well.sf.ca.us>, gurgle@well (Pete Gontier) writes: >Whoa there! You don't need to do an _InitGraf in a DA! And if you do find >a reason to do it, certainly don't do it relative to A5, because you're >likely to trash your host application's QuickDraw. If you really need to >do it (and you probably don't), make sure you have your own space for >QuickDraw globals and send THAT to _InitGraf. 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...? >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. Charles Martin // martin@cs.uchicago.edu
gandalf@apple.com (Martin Gannholm) (01/31/91)
In article <22935@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: > In article <1991Jan26.210319.3409@midway.uchicago.edu> martin@cs.uchicago.edu writes: > >For some reason Hypercard (also Microsoft Word) doesn't like the MENU > >that I'm adding from my INIT/DRVR: > > > >The INIT that does an OpenDeskAcc. In the open routine of the DRVR, I > >do (abbreviated): > > > > PEA -4(A5) > > _InitGraf > > InitFonts; > > GetMenu > > DetachResource > > Whoa there! You don't need to do an _InitGraf in a DA! And if you do find a > reason to do it, certainly don't do it relative to A5, because you're likely > to trash your host application's QuickDraw. Exactly. Gontier goes on to say: > Finally, re: MS Word and HyperCard, good luck. They've always been notorious > as rule breakers. OK, the original version of HyperCard was a rule breaker in a big way. I'd just like to clear the record that we did everything we could to follow the rules in HyperCard 2.0. A fair piece of the 2.0 effort was in rewriting many parts in order to follow the rules of IM. Some parts that spring to mind are: all file manager stuff; all use of QuickDraw (remember, Bill wrote QuickDraw too, so he knew how to bend the rules); menu handling; window handling...and a lot more. Martin Gannholm HyperCard 2.0 Engineer Apple Computer Exclaimer!!! I never said it...Nobody heard me say it...You can't prove anything!
gurgle@well.sf.ca.us (Pete Gontier) (02/05/91)
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.