bernard@boulder.colorado.edu (Bernie Bernstein) (01/17/91)
I would like to allow the user to grow a window to the size of his/her
largest monitor or beyond. I have noticed that in the Finder, the size
of the folder windows may not exceed the size of the main monitor (the one
with the menu bar) even if the window is in a larger monitor. I want to
avoid this problem by asking how one properly gets the sizeRect for
GrowWindow.
If sizeRect is the size of the main monitor, then it can not be
grown for any larger monitors. If it is defined by the monitor containing
the upper-left corner of the window, then the window can not be
grown into a second monitor. Should I make it the union of the rects
from all monitors? Is there a guideline about this?
Talk to me.
o, ,, , | Bernie Bernstein | , ,,
L>O/ \,/ \ ,| University of Colorado at boulder |/ \,,/ \
O./ ' / . `, / | office: (303) 492-8136 | / ` \ ,.
,/ / , ' | email: bernard@boulder.colorado.edu | / '' \bin@primate.wisc.edu (Brain in Neutral) (01/18/91)
From article <1991Jan16.231355.3992@csn.org>, by bernard@boulder.colorado.edu (Bernie Bernstein): > I would like to allow the user to grow a window to the size of his/her > largest monitor or beyond. I have noticed that in the Finder, the size > of the folder windows may not exceed the size of the main monitor (the one > with the menu bar) even if the window is in a larger monitor. I want to > avoid this problem by asking how one properly gets the sizeRect for > GrowWindow. Call GetGrayRgn() to get the region defining the desktop area (union of screen areas - menu bar), and use the bounding box of the region. This is somewhere in Inside Macintosh V (Graphics Device chapter, I believe). Possibly you need to check whether the trap exists and use the low memory global GrayRgn instead if it doesn't. Of course, depending on how GetGrayRgn() is implemented, it might simply return the value of GrayRgn itself! Anyone know? -- Paul DuBois dubois@primate.wisc.edu
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/18/91)
In article <3770@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >This is somewhere in Inside Macintosh V (Graphics Device chapter, I believe). >Possibly you need to check whether the trap exists and use the low memory >global GrayRgn instead if it doesn't. Of course, depending on how >GetGrayRgn() is implemented, it might simply return the value of GrayRgn >itself! Anyone know? GetGrayRgn ( ) is [ Not In ROM ] - if the call's not there, the global ain't either. Check for old ROMs or something instead... New Sys software should provide the GetGrayRgn ( ) call on any machine. h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
bin@primate.wisc.edu (Brain in Neutral) (01/19/91)
From article <1991Jan18.153558.4723@nada.kth.se>, by d88-jwa@dront.nada.kth.se (Jon W{tte):
| In article <3770@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
|
|>This is somewhere in Inside Macintosh V (Graphics Device chapter, I believe).
|>Possibly you need to check whether the trap exists and use the low memory
|>global GrayRgn instead if it doesn't. Of course, depending on how
|>GetGrayRgn() is implemented, it might simply return the value of GrayRgn
|>itself! Anyone know?
| GetGrayRgn ( ) is [ Not In ROM ] - if the call's not there, the
| global ain't either. Check for old ROMs or something instead...
| New Sys software should provide the GetGrayRgn ( ) call on any
| machine.
Well, um. I have written a "tell me about this system" application that
looks at both the GetGrayRgn() result and at GrayRgn. The systems I've
run this on so far show identical results. Just like for GetMBarHeight()
and MBarHeight (although this latter test would certainly fail on 64K ROM
machines, since they have no MBarHeight global according to TN 117 p7).
Just because the glue code executed for GetGrayRgn() isn't
in ROM doesn't mean it doesn't access any globals. It might not,
but I doubt that the absence of the global can't be inferred from
the presence of the function.
Paul DuBois
dubois@primate.wisc.edulsr@Apple.com (Larry Rosenstein) (01/19/91)
In article <1991Jan18.153558.4723@nada.kth.se>, d88-jwa@dront.nada.kth.se (Jon W{tte) writes: > > GetGrayRgn ( ) is [ Not In ROM ] - if the call's not there, the > global ain't either. Check for old ROMs or something instead... > New Sys software should provide the GetGrayRgn ( ) call on any > machine. The GrayRgn low memory global has been in the system from the very beginning. The current MPW interfaces implements GetGrayRgn as an inline that simply accesses the global. The designation Not in ROM simply means there is no trap call, so that the routine is either implemented in glue or as an inline.
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/19/91)
In article <3777@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >| GetGrayRgn ( ) is [ Not In ROM ] - if the call's not there, the >| global ain't either. Check for old ROMs or something instead... >but I doubt that the absence of the global can't be inferred from >the presence of the function. Erh... the _absence_ of the _global_ _can't_ be inferred from the precense of the function... Too many negations: Stack overflow ;-) You seem to indicate that you think that if the call's there, the global isn't - I feel rather strongly that the absence of the call indicates no global, but the call may be implemented for 64K macs, even though they have no global. h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se This article is fake. If you take it for real, the _REAL_ Jon W{tte will sue you for slander. So there !