[comp.sys.mac.programmer] LSC and &screenBits.bounds

stuartb@microsoft.UUCP (Stuart Burden) (05/05/89)

I have a two part query that I'm hoping someone will be able to help me with.

If I do:

  tempRect = screenBits.bounds;
  DragWindow(myWindow, myEvent->where, &tempRect);

I am limited to draging my window within the current display (not across
multiple monitors).  The same is true, if I do a SetRect for the Rect
using the screenBits.bounds members.

However, if I perform the DragWindow using the address of sreeenBits.bounds:

  DragWindow(myWindow, myEvent->where, &screenBits.bounds);

this will let me drag my window across multiple displays.  I'm curious as
to why LSC would special case the address of and not the structure members?

The next logical thing I would like to do is to open a window that spans
more than one monitor.  If I use screenBits.bounds to set the rect for
my window, I am limited to the primary display.  I have tried using
an assignment from (**GrayRgn).rgnBBox, but this again only seems to let
me size my windows portRect to the size of the primary display.

If someone could point out a better/correct way to do this, and maybe an
example, I'd appreciate it.

Thanks in advance,

Stu.


__Paths to my door:_______________________
microsoft!stuartb@beaver.cs.washington.edu  -   Usual disclaimer, that all
microsoft!stuartb@uw-beaver.arpa            -   the above is pure fantasy
microsoft!stuartb@uunet.UU.NET              -       and Microsoft only
[DE01HB]stuartb@DASNET#   {from AppleLink}  -    gave me the Mountain Dew
stuartb@microsoft.uucp    {well connected}  -      to dream it all in a
D2012 {@applelink.apple.com - shared acct}  -        caffeine haze :-)
__________________________________________________________________________

oster@dewey.soe.berkeley.edu (David Phillip Oster) (05/05/89)

In article <5652@microsoft.UUCP> stuartb@microsoft.UUCP (Stuart Burden) writes:
>  tempRect = screenBits.bounds;
>  DragWindow(myWindow, myEvent->where, &tempRect);

>I am limited to draging my window within the current display (not across
>multiple monitors).
>However, if I perform the DragWindow using the address of sreeenBits.bounds:
>  DragWindow(myWindow, myEvent->where, &screenBits.bounds);
>this will let me drag my window across multiple displays.  I'm curious as
>to why LSC would special case the address of and not the structure members?
This special case kludge is done by the operating system, not L.S.C.,
There is another kludge that will give you full dragging if you follow the
guidelines in IM Vol1:
	tempRect = screenBits.bounds;
	tempRect.top += GetMenuBarHeight();
	InsetRect(&tempRect, 4, 4);
	DragWindow(myWindow, event->where, &tempRect);

Since these are kludges, I'm not sure whether to advise you to use them,
or to 	tempRect = (**grayRgn).rgnBBox;  (which, in theory, allows the
user to drag the window off the screeen if the CRTs are arranged in an "L"
configuration.) I follow IM's guidelines.

>The next logical thing I would like to do is to open a window that spans
>more than one monitor.  If I use screenBits.bounds to set the rect for
>my window, I am limited to the primary display.  I have tried using
>an assignment from (**GrayRgn).rgnBBox, but this again only seems to let
>me size my windows portRect to the size of the primary display.
(**grayRgn).rgnBBox should be okay. I usually set up my windows so the
zoom box makes the window as big as the monitor the window is mostly on,
but the user can always drag the grow box while holding down the command
key to make the window as big as he wants.

When I was writing the Barneyscan Mac scanner drivers, I'd often hook up
two 24-bit per pixel, 19" monitors side by side, and make one window span
both displays.  It was the only way I could see the full 4.5 megabyte
image the scanner produces without zooming the image to shrink it. Since
the software can resize to interpolate the image even largrer, it would
have been fun to hook up four of these beasts and have one image fill them
all, but my manager never quite got it together for me to work on a Mac II
that overextended.

--- David Phillip Oster            --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee