t-jacobs@wasatch.UUCP (Tony Jacobs) (11/26/88)
I'm sure this has passed through here before but could someone elaborate on how to draw into the region where the menu is or drawing onto the whole screen. I've been told that perhaps you need to skip doing a InitMenu and then do a SetPort to the WMgrPort but that doesn't appear to do the trick. This is being done in Lightspeed C 3.0 so any C source would help but any language could be interpreted providing the toolbox keyword appear. -- Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu
jkjl@munnari.oz (John Lim) (11/27/88)
In article <616@wasatch.UUCP>, t-jacobs@wasatch.UUCP (Tony Jacobs) writes: > I'm sure this has passed through here before but could someone elaborate on > how to draw into the region where the menu is or drawing onto the whole screen. > I've been told that perhaps you need to skip doing a InitMenu and then do a > SetPort to the WMgrPort but that doesn't appear to do the trick. > > This is being done in Lightspeed C 3.0 so any C source would help but any > language could be interpreted providing the toolbox keyword appear. > Try this : { WindowPtr windP; windP = NewWindow(... with the bounds set the screenBits.bounds...); UnionRgn(windP->visRgn,WMgrPort->visRgn,windP->visRgn); } In normal windows the visRgn excludes the menubar, but the WMgrPort visRgn includes the whole screen. Since the regions are both in global coords, no problems doing an UnionRgn().
nicky@cup.portal.com (nick john pilch) (11/29/88)
>Try this : > >{ >WindowPtr windP; > > windP = NewWindow(... with the bounds set the screenBits.bounds...); > UnionRgn(windP->visRgn,WMgrPort->visRgn,windP->visRgn); > >} > >In normal windows the visRgn excludes the menubar, but the WMgrPort >visRgn includes the whole screen. Since the regions are both in global coords, >no problems doing an UnionRgn(). Watch out. You altering the visRgn of a window, which is a no-no, especially under Multifinder. Nick Pilch nicky@cup.portal.com
jjoshua@topaz.rutgers.edu (Jon Joshua) (06/18/90)
I want to write a utility that monitors SCSI activity and places a
small mark in the menu bar (to the left of the apple). What would be
the preferred way to draw something in the menu bar? I probably
wouldn't actually draw something, though.... I think that I'll just
reverse some bits.
JOn.
--
/\ ? ________________
jjoshua@topaz.rutgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__tj@cs.ucla.edu (Tom Johnson) (07/25/90)
I'm sure that this has been tossed around here before, but I guess I missed
it. How do you draw in the menu bar? I am writing an INIT that will put
a SICN up in the menu bar (like OnCue, Multifinder, EasyAccess, etc...).
I have set the port to the wMgrPort, and tried to CopyBits to it, but
it is getting clipped. Trying to change the ClipRect seems to have no
effect. Am I missing something obvious? How do all you guys do it?
Ideas/thoughts/source-code greatly appreciated.
Thanks--
Tom
--
Tom Johnson UCLA Computer Science Department
3413 Boelter Hall, Los Angeles CA 90024 (213)825-6952
Internet: tj@cs.ucla.edustevec@Apple.COM (Steve Christensen) (07/25/90)
In article <37238@shemp.CS.UCLA.EDU> tj@cs.ucla.edu (Tom Johnson) writes: >I'm sure that this has been tossed around here before, but I guess I missed >it. How do you draw in the menu bar? I am writing an INIT that will put >a SICN up in the menu bar (like OnCue, Multifinder, EasyAccess, etc...). >I have set the port to the wMgrPort, and tried to CopyBits to it, but >it is getting clipped. Trying to change the ClipRect seems to have no >effect. Am I missing something obvious? How do all you guys do it? Setting the clipRect to the full screen doesn't do it (I haven't tried that)? I've just created a private GrafPort and set the clipRect to full screen and then drawn whatever I want. I don't think I've had to do anything more special than that... steve -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: CHRISTENSE1 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
aries@rhi.hi.is (Reynir Hugason) (07/26/90)
>>I'm sure that this has been tossed around here before, but I guess I missed >>it. How do you draw in the menu bar? I am writing an INIT that will put >>a SICN up in the menu bar (like OnCue, Multifinder, EasyAccess, etc...). >>I have set the port to the wMgrPort, and tried to CopyBits to it, but >>it is getting clipped. Trying to change the ClipRect seems to have no >>effect. Am I missing something obvious? How do all you guys do it? >Setting the clipRect to the full screen doesn't do it (I haven't tried that)? >I've just created a private GrafPort and set the clipRect to full screen and >then drawn whatever I want. I don't think I've had to do anything more >special than that... If you feel that you really, really, really ... really must draw in the wMgrPort then you can do the following: Fetch the current visRgn and store it. Create a new visRgn, which covers the entire screen. Draw to your heart's content. Dispose of your visRgn and restore the old one. But remember on future systems your program will probably be singing LA BOMBA, so don't use the wMgrPort - open up your own! You have been warned. --- Mimir (aries@rhi.hi.is) - Aries, Inc.
jjoshua@remus.rutgers.edu (The Twigster) (08/01/90)
I would like to get a difinitive answer someday...
I am writing something similar to InUse
I want to open a GrafPort for drawing. It should include the menu
bar. I have been just writing directly to WMgrPort's bit map using
different routines to handle different screen depths. After reading
TN 194 I decided that I should use OpenPort() and QuickDraw calls.
The problem is that I am getting a crash in OpenPort(). The code is
getting called from a trap patch to _SCSIDispatch.
Help Please!
--
/\ ? ________________
jjoshua@topaz.rutgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__stevec@Apple.COM (Steve Christensen) (08/02/90)
In article <Jul.31.17.24.56.1990.25035@remus.rutgers.edu> jjoshua@remus.rutgers.edu (The Twigster) writes: >I am writing something similar to InUse. >I want to open a GrafPort for drawing. It should include the menu >bar. I have been just writing directly to WMgrPort's bit map using >different routines to handle different screen depths. After reading >TN 194 I decided that I should use OpenPort() and QuickDraw calls. > >The problem is that I am getting a crash in OpenPort(). The code is >getting called from a trap patch to _SCSIDispatch. If you want to work in a manner similar to InUse, you can't use QuickDraw. Period. _SCSIDispatch can be called at any time, even in response to an interrupt. QuickDraw uses the Memory Manager which means that you can't use QuickDraw to do any drawing during an interrupt. If you want to find out more about what Sam Barone did to get InUse to work you might drop him a note at yngwie@apple.com. Better yet, instead of re-inventing the wheel, why not just use InUse??? steve :-) -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: STEVEC 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
jimc@isc-br.ISC-BR.COM (Jim Cathey) (08/02/90)
In article <9536@goofy.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >If you want to work in a manner similar to InUse, you can't use QuickDraw. >Period. _SCSIDispatch can be called at any time, even in response to an >interrupt. QuickDraw uses the Memory Manager which means that you can't >use QuickDraw to do any drawing during an interrupt. Well, that's a bit harsh isn't it? Althought QD _can_ call the Memory Manager, it doesn't always do it. The things to avoid are opening and closing ports (which manipulate clipping regions), text drawing (if the font is unloaded), stretching versions of CopyBits (where it sucks up stack space), and many of the calls that refer to regions. Small 1:1 CopyBits, EraseRects, and the like should be just fine, shouldn't they? +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
minow@mountn.dec.com (Martin Minow) (08/03/90)
In article <2900@isc-br.ISC-BR.COM> jimc@isc-br.ISC-BR.COM (Jim Cathey) writes: >Small 1:1 >CopyBits, EraseRects, and the like should be just fine, shouldn't they? No. Would you like to see the scars? EraseRect (to take one example) is explicitly marked as "may move memory." In fact, not even InvalRect is safe. To return to the original question, there are two techniques you can use to draw over the menubar: -- save the old MBarHeight, set it to zero and (I'm not sure what happens next, but I think you can now open a window that covers the screen). Advantage: SuperClock and notification stuff shut up. Disadvantage: Better restore the MBarHeight before your program exits! -- Hack: the following worked for me: SelectWindow(window); ObscureCursor(); ShowWindow(window); /* * This is needed to get a full-screen window. * It effectively hides the menu bar. It must * be after ShowWindow(). * * The update event eventually causes the display to happen. */ CopyRgn(window->clipRgn, window->visRgn); SetPort(window); InvalRect(&thePort->portRect); Advantage: No loss if your program crashes. Disadvantage: Notifications and SuperClock (and anything else that tries to draw in the MenuBar) overwrite your window. I used this hack for a program that runs on a display server -- the "window" is the only thing that is visible, and there is no interaction on that computer. MacDTS steadfastly refuses to tell us weenies the "approved" method. Martin Minow minow@bolt.enet.dec.com
norman@d.cs.okstate.edu (Norman Graham) (08/03/90)
From article <1816@mountn.dec.com>, by minow@mountn.dec.com (Martin Minow): > To return to the original question, there are two techniques you can use > to draw over the menubar: > > -- save the old MBarHeight, set it to zero and (I'm not sure what happens next, > but I think you can now open a window that covers the screen). > Advantage: SuperClock and notification stuff shut up. > Disadvantage: Better restore the MBarHeight before your program exits! As of MultiFinder 6.0.5, each process gets its own MBarHeight; thus if your process crashes or you forget to reset MBarHeight, it won't have an effect on other processes' MBarHeight. Disclaimer: That's what the System 6.0.5 Draft Change History said anyway. Norm -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences BangPath: 219 Mathematical Sciences Building {cbosgd,rutgers}!okstate!norman Stillwater, OK USA 74078-0599
J.COOK@ENS.Prime.COM (08/06/90)
jjoshua@remus.rutgers.edu asked "Drawing in the menu bar (AGAIN)
There is a simple basic answer regarding how to draw in the menu bar.
Look at the sample program "Flying Line" in "Macintosh Programming Primer"
by Mark & Reed.
They create a window "gLineWindow" that is black and occupies the entire
screen including the menubar. Don't send the Apple Thought Police after
me for this - see Mark & Reed.
#define NIL_POINTER 0L
#define MOVE_TO_FRONT -1L
#define NIL_STRING "\p"
#define NIL_TITLE NIL_STRING
#define VISIBLE TRUE
#define NO_GO_AWAY FALSE
#define NIL_REF_CON NIL_POINTER
WindowPtr gLineWindow;
int gOldMBarHeight;
WindowInit()
{
Rect totalRect, mBarRect;
RgnHandle mBarRgn;
gOldMBarHeight = MBarHeight;
MBarHeight = 0;
gLineWindow = NewWindow( NIL_POINTER, &(screenBits.bounds),
NIL_TITLE, VISIBLE, plainDBox, MOVE_TO_FRONT, NO_GO_AWAY,
NIL_REF_CON );
SetRect( &mBarRect, screenBits.bounds.left, screenBits.bounds.top,
screenBits.bounds.right, screenBits.bounds.top+gOldMBarHeight);
mBarRgn = NewRgn();
RectRgn( mBarRgn, &mBarRect );
UnionRgn( gLineWindow->visRgn, mBarRgn, gLineWindow->visRgn );
DisposeRgn( mBarRgn );
SetPort( gLineWindow );
FillRect( &(gLineWindow->portRect), black );
}
Note that before the program exits, it set MBarHeight back to the value saved
in gOldMBarHeight.
Jim Cook
J.COOK@ENS.Prime.COM
"Just my misinformation. Prime has it's own."stevec@Apple.COM (Steve Christensen) (08/06/90)
In article <2900@isc-br.ISC-BR.COM> jimc@isc-br.ISC-BR.COM (Jim Cathey) writes: >In article <9536@goofy.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >>[...can't use QuickDraw in an interrupt handler, etc...] > >Well, that's a bit harsh isn't it? Althought QD _can_ call the Memory >Manager, it doesn't always do it. The things to avoid are opening and >closing ports (which manipulate clipping regions), text drawing (if the >font is unloaded), stretching versions of CopyBits (where it sucks up >stack space), and many of the calls that refer to regions. Small 1:1 >CopyBits, EraseRects, and the like should be just fine, shouldn't they? As I recall (not being a total QD guru myself), QD lives on regions even for little things like 1:1 CopyBits, lines, rects, etc., since it has to determine if what you're drawing is all inside the port or not (and clipping it if not). Remember that a port could have some bizarre [non-rectangular] clipRgn... steve -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: STEVEC 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
jimc@isc-br.ISC-BR.COM (Jim Cathey) (08/08/90)
In article <1816@mountn.dec.com> minow@bolt.enet.dec.com (Martin Minow) writes: >>Small 1:1 >>CopyBits, EraseRects, and the like should be just fine, shouldn't they? >No. Would you like to see the scars? EraseRect (to take one example) is >explicitly marked as "may move memory."... Too bad. It used to be safe (See Appendix A of IM-III and IM-IV). I will admit that my Mac knowledge is B&W based, and that I have not kept up very well, but it seems like Apple really screwed the pooch on this one if they by (fiat or poor design) declared all drawing traps as unsafe for Color QD and beyond. I hear that asynchronous file opens are due to go the same way when Sys 7 hits the street. Wonderful. Even more features that were damned handy and impossible to fake being deleted in the name of progress. This system is starting to feel more like a PC all the time. >...In fact, not even InvalRect is safe. I would never have expected this one to be safe as its job is to _modify_ regions. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
lippin@ragu.berkeley.edu (The Apathist) (08/14/90)
In article <1816@mountn.dec.com> minow@bolt.enet.dec.com (Martin Minow) writes: >EraseRect (to take one example) is explicitly marked as "may move >memory."... Recently jimc@isc-br.ISC-BR.COM (Jim Cathey) wrote: >Too bad. It used to be safe (See Appendix A of IM-III and IM-IV). Not by the IM-III I have here. It's a recent edition, but it claims not to have been changed. And I remember drawing at interrupt time being illegal even back when I was using the phone book edition. Also, the question of modifying regions hardly enters into the discussion -- the title of the list "Routines That May Move or Purge Memory" is a misnomer. It's really "Routines Which are Unsafe at Interrupt Time." You can't draw at interrupt time because QuickDraw isn't reentrant. It forgets, for example, whether the cursor is showing. Kind of confusing for normal use, but great for drawing pine forests in a high wind :-). --Tom Lippincott lippin@math.berkeley.edu "If it was so, then it would be, and if it were so, then it could be, but as it isn't, it ain't. That's Logic." --Tweedledee
lsr@Apple.COM (Larry Rosenstein) (08/15/90)
In article <1990Aug14.031613.18374@agate.berkeley.edu> lippin@math.berkeley.edu writes: >Interrupt Time." You can't draw at interrupt time because QuickDraw >isn't reentrant. It forgets, for example, whether the cursor is Plus, a grafPort contains several handles (clipRgn, visRgn, ...) which QuickDraw uses and aren't guaranteed to be valid at interrupt level (unless locked). -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr