David_Anthony_Guevara@cup.portal.com (03/16/89)
I am posting this for a friend. Please try to direct your responses to him
at the addresses listed below. If all else fails, forward your responses to
me and I will pass them on to Bob. Thanks!
=============================================================================
I am writing an application which contains a "welcome" screen. I would like
this window to occupy the entire Mac+ screen, but I can not get rid of the
blank menu bar which is occupying 20 pixels at the top of the screen. I am
working in Lightspeed C 3.01. Does anyone know how to get it so that the
menu bar is not drawn? I have tried doing a menuinit() call after the
welcome screen, but no success.
Thanks,
Robert Ruderman
UUCP: "...claris!laic!force!ruderman"
Internet: "...claris!laic!force!ruderman@pyramid.pyramid.com"
==============================================================================
If you can't get to either one of those addresses send your replies to me at
UUCP: "...sun!cup.portal.com!David_Anthony_Guevara" or
"David_Anthony_Guevara@cup.portal.com"
and I will forward them to him. Thanks for any help you may be able to give!
Dave Guevarabeard@ux3.lbl.gov (Patrick C Beard) (03/25/89)
In article <15866@cup.portal.com> David_Anthony_Guevara@cup.portal.com writes: >I am writing an application which contains a "welcome" screen. I would like >this window to occupy the entire Mac+ screen, but I can not get rid of the >blank menu bar which is occupying 20 pixels at the top of the screen. I am >working in Lightspeed C 3.01. Does anyone know how to get it so that the >menu bar is not drawn? >Thanks, > > Robert Ruderman I am posting this as it may be of general interest. The only way that I've found for removing the menu bar is to open a grafport (not a window), and fill it with the deskttop pattern. This will draw over the menu bar. As far as I know, though, there is no way to have a window overlay the menu bar. I hope this helps. +----------------------------------------------------------------+ \ Patrick Beard "Badges? \ \ Berkeley Systems, Inc. I ain't got to show you... \ \ PCBeard@lbl.gov ...NO STINKING BADGES!" \ + ---------------------------------------------------------------+
phssra@mathcs.emory.edu (Scott R. Anderson) (03/26/89)
In article <2214@helios.ee.lbl.gov> beard@ux3.lbl.gov (Patrick C Beard) writes: >In article <15866@cup.portal.com> David_Anthony_Guevara@cup.portal.com writes: >>I am writing an application which contains a "welcome" screen. I would like >>this window to occupy the entire Mac+ screen, but I can not get rid of the >>blank menu bar which is occupying 20 pixels at the top of the screen. I am >>working in Lightspeed C 3.01. Does anyone know how to get it so that the >>menu bar is not drawn? > >I am posting this as it may be of general interest. The only way that I've >found for removing the menu bar is to open a grafport (not a window), and >fill it with the deskttop pattern. This will draw over the menu bar. As >far as I know, though, there is no way to have a window overlay the menu >bar. I hope this helps. It *is* possible to cover the entire screen, including the menu bar, by simply redefining the variable GrayRgn, which defines the region where windows can be drawn. (I'm not sure why this information is so obscure, since so many people seem to need it.) Here is a fragment which has done the job for me: RgnHandle oldGrayRgn, allScreen; oldGrayRgn = GrayRgn; allScreen = NewRgn(); RectRgn(allScreen, &screenBits.bounds); GrayRgn = allScreen; You can then open a window which will not be clipped to the old GrayRgn. * * ** Scott Robert Anderson gatech!emoryu1!phssra * * * ** phssra@unix.cc.emory.edu phssra@emoryu1.bitnet * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
svc@well.UUCP (Leonard Rosenthol) (03/27/89)
In article <3858@emory.mathcs.emory.edu>, phssra@mathcs.emory.edu (Scott R. Anderson) writes: > In article <2214@helios.ee.lbl.gov> beard@ux3.lbl.gov (Patrick C Beard) writes: > >In article <15866@cup.portal.com> David_Anthony_Guevara@cup.portal.com writes: > >> [ Discussion to a full screen window] > > It *is* possible to cover the entire screen, including the menu bar, by simply > redefining the variable GrayRgn, which defines the region where windows can be > drawn. > Although this will work, Apple has said before that the GrayRgn is READONLY! You are NOT to modify it! Especially under MF this is an even BIGGER no-no since you are doing this behind the back of other apps and the GrayRgn is a LMGlobal and the effect is VERY interesting. Now that I've done Apple's job for them, I'll expect the check in the mail ;-) -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
phssra@mathcs.emory.edu (Scott R. Anderson) (04/02/89)
In article <2214@helios.ee.lbl.gov> beard@ux3.lbl.gov (Patrick C Beard) writes: >I am writing an application which contains a "welcome" screen. I would like >this window to occupy the entire Mac+ screen, but I can not get rid of the >blank menu bar which is occupying 20 pixels at the top of the screen. >In article <3858@emory.mathcs.emory.edu>, I wrote: > It *is* possible to cover the entire screen, including the menu bar, by simply > redefining the variable GrayRgn, which defines the region where windows can be > drawn. In article <11118@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: > Although this will work, Apple has said before that the GrayRgn is >READONLY! You are NOT to modify it! Especially under MF this is an even BIGGER >no-no since you are doing this behind the back of other apps and the GrayRgn >is a LMGlobal and the effect is VERY interesting. I imagine this prohibition is in the tech notes, since it isn't mentioned in Inside Mac where GrayRgn is defined. I defer to Leonard's vastly greater wisdom. Now if he had just given *his* solution to this problem. (I only provided mine because no one else seemed to be volunteering the information.) It has also been pointed out to me by others that the method I provided would not work with multiple monitors, since screenBits.bounds only describes the main screen. If you like to play with fire, you might redefine GrayRgn to be its bounding box; this will give you a rectangle which will be sure to include all monitors. To ensure that you include the menubar, also, this rectangle should contain screenBits.bounds. * * ** Scott Robert Anderson gatech!emoryu1!phssra * * * ** phssra@unix.cc.emory.edu phssra@emoryu1.bitnet * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
svc@well.UUCP (Leonard Rosenthol) (04/03/89)
In article <3867@emory.mathcs.emory.edu>, phssra@mathcs.emory.edu (Scott R. Anderson) writes: > In article <2214@helios.ee.lbl.gov> beard@ux3.lbl.gov (Patrick C Beard) writes: >> [Previous discussion about FullScreen Dialogs (ie. cover the menu bar) >> There is no CLEAN solution to the problem of using the whole screen (ie. covering the menubar) but the one that I prefer as it does not mess with the GrayRgn (and it is what Hypercard does) is to actually remove the MenuBar and then let the OS redefine the GrayRgn for you. The following outline of the procedure should give you an idea of what to do to get rid of the menuBar - JUST REMEMBER that if the user could somehow switch out of your application while the menuBar is gone - you had better check for it and handle it properly! Get the MenuBar height (either use GetMBarHeight or check $BAA) Set the MenuBar height to 0 (set $BAA to 0 yourself) Call DrawMenuBar (this will get the OS to reset the GrayRgn for you) Get the GrayRgn (use GetGrayRgn) and use it to draw the screen Reset the MenuBar height to the saved value (set $BAA to the saved value) Call DrawMenuBar (reset the GrayRgn back for you) That's All Folks!!! -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
svc@well.UUCP (Leonard Rosenthol) (04/03/89)
In article <11208@well.UUCP>, svc@well.UUCP (Leonard Rosenthol) writes: > In article <3867@emory.mathcs.emory.edu>, phssra@mathcs.emory.edu (Scott R. Anderson) writes: > > In article <2214@helios.ee.lbl.gov> beard@ux3.lbl.gov (Patrick C Beard) writes: > >> [Previous discussion about FullScreen Dialogs (ie. cover the menu bar) > >> > [Suggestions of how to do it by killing the MenuBar] > There is one other solution which is MUCH cleaner, and is probably a better way to do it. There is this neat thing called the WindowMgrPort (you can get it using the GetWMgrPort(VAR wPort:GrafPtr) call ($A910)) which is a GrafPort which covers the entire desktop (including multiple monitors). You can then make a copy of the WMgrPort (NEVER draw into the real WMgrPort!) and then draw into the new copy whose origin is at 0,0 (so over the menuBar). -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
sho@pur-phy (Sho Kuwamoto) (04/04/89)
In article <11208@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: <In article <3867@emory.mathcs.emory.edu>, phssra@mathcs.emory.edu (Scott R. Anderson) writes: < There is no CLEAN solution to the problem of using the whole screen <(ie. covering the menubar) but the one that I prefer as it does not mess with <the GrayRgn (and it is what Hypercard does) is to actually remove the MenuBar <and then let the OS redefine the GrayRgn for you. < The following outline of the procedure should give you an idea of what <to do to get rid of the menuBar - JUST REMEMBER that if the user could somehow <switch out of your application while the menuBar is gone - you had better <check for it and handle it properly! < <Get the MenuBar height (either use GetMBarHeight or check $BAA) <Set the MenuBar height to 0 (set $BAA to 0 yourself) <Call DrawMenuBar (this will get the OS to reset the GrayRgn for you) <Get the GrayRgn (use GetGrayRgn) and use it to draw the screen <Reset the MenuBar height to the saved value (set $BAA to the saved value) <Call DrawMenuBar (reset the GrayRgn back for you) Interesting. I am surprised that this is the way Hypercard does it. I assumed it screwed up the GrayRgn itself, because the rounded corners become square. Do the ROM routines just leave the GrayRgn as a rectangle if the MBarHeight is zero? If so, why? -Sho