Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!europa.asd.contel.com!sura.net!haven!ni.umd.edu!ni.umd.edu!zben From: zben@ni.umd.edu (Ben Cranston) Newsgroups: comp.sys.mac.programmer Subject: Re: Disabling menus when DA's are closed Summary: We're talking about menu HEADERS not ITEMS Message-ID: <1991Mar6.174029.4706@ni.umd.edu> Date: 6 Mar 91 17:40:29 GMT References: <1.27D17B52@mmug.edgar.mn.org> <3BRcy1w163w@shark.cs.fau.edu> <1991Mar6.074201.13324@nada.kth.se> Sender: usenet@ni.umd.edu (USENET News System) Organization: University of Maryland at College Park Lines: 53 Nntp-Posting-Host: ni.umd.edu In article <1991Mar6.074201.13324@nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: > Bzzzzt. I'm sorry. You were all very close, but step down behind > the curtains and we'll have some fabulous consolation prizes for > you. Mighty gratuitous, especially since you COMPLETELY misunderstood the actual subject of this thread... > The right answer is, of course, to check the windowKind of the > FrontWindow just before you call MenuSelect or MenuKey - it's > that simple. There won't be any noticeable delay before the menu > appears either (not even on the Classic...) I've used this technique, though accidently omitting the check before MenuKey introduced a very subtle bug in one of my applications. This approach works fine for turning menu ITEMS (the things that only appear when you mouse down on the menu TITLE bar) on and off, since they are not visible until MenuSelect is called. However, the subject of this thread is making the menu TITLES, which are visible ALL THE TIME, dim and light. According to user interface rules when all the choices are dim the menu title itself should dim, if any choice is possible the menu title should be lighted. The quoted solution does NOT address this problem... As I said in private mail to the original poster, I've approached this problem by writing a "fixmenu" routine that examines FrontWindow and typically branches into three cases. In the case that FrontWindow is completely null (no windows on the screen at all) typically only OPEN and QUIT in the FILE menu get lit. If FrontWindow is one of MY windows then I do whatever is necessary, if not then FrontWindow is a DA window and I setup the menus for that case. I call "fixmenu" on every activate and deactivate event. When the front window changes you should get one or the other most of the time. The bad case is when there are none of your windows at all and a DA comes and goes. I could not think of a better solution than calling "fixmenu" after EVERY call to SystemClick. This causes the menu bar to blink with each DA click though. Sorry, I cannot think of a better solution than trapping a changing FrontWindow in the main event loop that will handle all cases. If anybody out there UNDERSTANDS the problem and has a better solution please post it. Ben Cranston Computer Science Center Network Infrastructures Group University of Maryland at College Park of Ulm "The good news is that Saddam Hussein will be prosecured for war crimes." "The bad news is that it will be before the Senate Ethics Committee..."