brian@ut-sally.UUCP (06/15/87)
Motivation: I'm writing a program that can have several windows and desk
accessories on the screen. When there are no windows or DAs on the screen, I
want the Close item in the File menu to be dimmed.
The first thought is that it's easy. As you process the Close menu item,
you just check to see if there are any windows left and if not, dim the menu
item. But suppose the only window on the screen is a DA. If the user clicks
the close box, the DA goes away, but the application is not informed. So here
you are, left with an empty screen and an enabled Close item.
The brute force method is to build the menu each time the user clicks in
the menu bar.
Is there a more elegant solution? Edit wimps out and never lets you
choose "Close" when a DA is in front. MacWrite, however, handles it the way I
want to. Thanks in advance for any help.
Brian H. Powell
UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
_Work_ _Not Work_
Department of Computer Sciences P.O. Box 5899
Taylor Hall 2.124 Austin, TX 78763-5899
The University of Texas at Austin (512) 346-0835
Austin, TX 78712-1188
(512) 471-9536han@apple.UUCP (Byron Han) (06/15/87)
In article <8259@ut-sally.UUCP>, brian@ut-sally.UUCP (Brian H. Powell) writes: > > Motivation: I'm writing a program that can have several windows and desk > accessories on the screen. When there are no windows or DAs on the screen, I > want the Close item in the File menu to be dimmed. > > The brute force method is to build the menu each time the user clicks in > the menu bar. > > Is there a more elegant solution? Try waiting until there is a Null Event returned from GNE. And then check to see if FrontWindow = Nil, then disable else Enable or alternatively, after each MouseDown in the GoAway region of the window, or each call to SystemClick, check the frontwindow to see if it is NIL and then disable/enable the CLOSE item. The second would give better results because if the user clicks in the close box and has other events queued up immediately after, the CLOSE item may not be immediately disabled. In fact, the best thing is to do both. Because, some action in the DA (via some keydown) may cause the window to go away. But then you should have some sanity checks in the CLose ROutine. I typically use this routine which is called in response to a mousedown in the GoAway part of the window that is the frontwindow (otherwise selectwindow is called) or to selecting CLOSE in the FILE menu. NOTE this is not meant to be final word - there are many ways to improve this code and this serves as a simple example. PROCEDURE DoClose; VAR theWindow : WindowPtr; theWIndowPeek : WindowPeek; BEGIN theWindow = FrontWindow; if theWindow <> NIL do begin theWIndowPeek = WindowPeek(theWIndow); if theWindowPeek^.windowKind = userKind do begin DoCloseMyWindow(theWindow); end else if theWindowPeek^.windowKind < 0 do begin CloseDeskAcc(theWIndowPeek^.windowKind); end; end; END; Hope this helps. ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN APPLELINK: HAN1 MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================
lsr@apple.UUCP (06/15/87)
In article <1036@apple.UUCP> han@apple.UUCP (Byron Han) writes: >In article <8259@ut-sally.UUCP>, brian@ut-sally.UUCP (Brian H. Powell) writes: >> >> Motivation: I'm writing a program that can have several windows and desk >> accessories on the screen. When there are no windows or DAs on the screen, I >> want the Close item in the File menu to be dimmed. >> >Try waiting until there is a Null Event returned from GNE. And then check >to see if FrontWindow = Nil, then disable else Enable > >or alternatively, after each MouseDown in the GoAway region of the window, or >each call to SystemClick, check the frontwindow to see if it is >NIL and then disable/enable the CLOSE item. > >The second would give better results because if the user clicks in the close >box and has other events queued up immediately after, the CLOSE item may >not be immediately disabled. Testing FrontWindow = NIL is the way to go, but I would make the check just before calling MenuSelect or MenuKey. The item doesn't have to be grayed out immediately, since it can't be seen unless the menu is pulled down. This has the advantages that it is always results in the correct menu highlighting (ie, you don't have to depend on catching a DA being closed) and the code only runs when it matters (just before a menu is pulled down). In addition, if the FrontWindow is not NIL, you should check to see if it has a goAway box. If the window does not have a goAway box, then Close should be disabled. In MacApp, we try to set up the menu state just before the menu is pulled down. If you do this, there are a couple of things to watch out for. You have to set up every menu. Once you call MenuSelect, the user can pull down any menu without your program getting a chance to intervene. You have to set up the menus before calling MenuKey as well. Even though the menu is not pulled down, MenuKey looks at the enable flags. If your Close item has a command key equivalent, then it can be chosen unless grayed out. Lastly, this technique doesn't work for graying out menu titles. It is unacceptable for a menu title to be grayed out after the user clicks on the menu bar. Menu titles have to be grayed out separately. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com