All DatabasesMacTech Vol 03-1987
Video
Volume Number: 3
Issue Number: 5
Column Tag: Assembly Language Lab
Video Independence
By Dan Weston, Macintosh Author
Working With Big Screens
The big screens are here. You've seen them at MacExpo in Boston and elsewhere.
Micrographix, E-machine, Radius; the names will soon be more familiar. And now the
Macintosh II and custom third party video boards and monitors will soon dominate the
Macintosh world. Will your applications run on the big screens?
If you've already been testing your programs on the Lisa/XL, then you probably
already know how to work with other screen sizes. But most of us are poking along
with a single Mac and we don't get a chance to play with the other members of the
Macintosh family.
It's really easy to make sure that your programs will take advantage of the big
screens. This short article shows how find out how big the current screen is and how
to grow and move your windows so that they can use the whole screen.
How Big is the Screen?
The first thing to do is check the Quickdraw globals for the screenbits.bounds
rectangle which gives the bounding rectangle for the whole screen. Quickdraw and the
window manager use this rectangle, so you might as well do it too.
GetScreenSize is a short assembly language subroutine that takes a pointer to a
rectangle variable and fills it in with the coordinates of screenbits.bounds.
; GetScreenSize.ASM
; This module finds out the size of the screen
; currently installed on your Mac
; It fills in a VAR rectangle with the coordinates
; of screenbits.bounds
INCLUDE QuickEqu.D
XDEF GetScreenSize
; Procedure GetScreenSize(VAR r:rect)
GetScreenSize:
r SET 8 ;offset to rectangle parameter
parambytes SET 4 ; bytes for parameter
LINK A6,#0 ; no locals
MOVE.L r(A6),A1 ; get dest rect
MOVE.L GrafGlobals(A5),A0 ; get QD globals
LEA screenBits+bounds(A0),A0
MOVE.L (A0)+,(A1)+ ; move the first part
MOVE.L (A0)+,(A1)+ ; move the rest
UNLK A6 ; get rid of stack frame
MOVE.L (SP)+,A0 ; return address
ADDA.W #parambytes,SP ; strip parameter
JMP (A0) ; return
GetScreenSize uses register A5 to get the pointer to the Quickdraw globals and
then offsets into the globals to get at screenbits.bounds. Then it copies the coordinates
into the VAR rectangle. If you are using a high level language, then you can probably
use an expression like
tempRect := screenbits.bounds;
Dragging a Window all Over Town
Once you have the screen dimensions (top and left of screenbits.bounds are
always 0,0) you can use them to guide window dragging and growing. For instance,
DragWindow takes a rectangle parameter that delimits the boundaries in which the
window may be dragged. A good strategy is to inset our copy of screenbits.bounds by
about 20 pixels so that at least part of the window will remain on the screen at all
times. Figure 1 shows just how far we can drag a window within the inset screen
rectangle. The code for doing this is shown below.
figure 1: DragWindow limits
;-------- DoDrag -------------
DoDrag
; The click was in the drag bar of the window. Drag it.
; xProcedure GetScreenSize(VAR r:Rect)
PEA tRect(A5) ; global scratch rect
JSR GetScreenSize
;Procedure InsetRect(VAR r:Rect;dh,dv:INTEGER)
PEA tRect(A5) ; the rect
MOVE.W #20,-(SP) ; dh
MOVE.W #20,-(SP) ; dv
_InsetRect
; DragWindow (theWindow:WindowPtr; startPt: Point;
boundsRect: Rect);
MOVE.L WWindow(A5),-(SP) ; Pass window
MOVE.L Point(A5),-(SP) ; mouse coordinates
PEA tRect(A5) ; and boundaries
_DragWindow ; Drag Window
BRA NextEvent ; Go get next event
Growing As Big as You Can
Another use for the screen boundaries is to govern GrowWindow so that your
windows can get as big as the biggest screen. GrowWindow takes a rectangle
parameter; the top and left coordinates specify the smallest vertical and horizontal
measurements the window can have. I choose 70 for each of these so that even the
smallest window will have complete scoll bars, including a thumb, as shown in figure
2.
Figure 2: GrowWindow limits
The bottom and right coordinates of the growrect parameter to GrowWindow
specify the maximum vertical and horizontal dimensions the window can have. The
bottom coordinate of screenbits.bounds, minus about 15 pixels, is good for the
maximum height. The maximum width should be wider than the screen, however, to
allow for stretching windows partially off the sides of the screen, as many people
learned to do with MacWrite. I chose the largest positive integer, $7FFF, for my
maximum width. Beware of using negative numbers for this parameter.
Interestingly enough, even though MacWrite will let you make a window much
wider than the screen, it seems to have the original Mac screen height hard-coded into
its grow routine. E-Machines includes a nice ROM patch with its big screen that lets
you hold down the option key while growing a window to override the limits that the
underlying program may be trying to impose on window size. The code fragment to
grow a window on an arbitrary screen is shown below.
;----------------- DoGrow ------------------------
DoGrow:
; first include scroll bar and grow region in update region
BSR InvalidScroll
; here is where we actually grow the window
; xProcedure GetScreenSize(VAR r:Rect)
PEA tRect(A5) ; global scratch rect
JSR GetScreenSize
ADD.W #70,tRect+top(A5) ; 70 pixels high
ADD.W #70,tRect+left(A5) ; 70 pixels wide
SUB.W #15,tRect+bottom(A5) ; not too tall
MOVE.W #$7FFF,tRect+right(A5) ;extra-wide OK
;FUNCTION GrowWindow(theWindow:WindowPtr;startPt:Point;
; sizeRect:Rect):LONGINT
CLR.L -(SP) ; space for result
MOVE.L WWindow(A5),-(SP) ; theWindow
MOVE.L Point(A5),-(SP) ; startPt
PEA tRect(A5) ; sizeRect
_GrowWindow
MOVE.W (SP)+,D1 ; new vertical dimension
MOVE.W (SP)+,D0 ; new horizontal dimension
; now draw it to the new size
True Confessions
It is really so easy to check the screen size that there is no excuse for not doing
it. I am sorry to say that I make the mistake of using hard-coded screen sizes in some
of my example programs in The Complete Book of Macintosh Assembly Langauge
Programming, Vol I. We all live and learn, I guess. I am preparing a list of other
things that could have been better in the book. Some suggestions have already come
from readers. I encourage you to send me your comments so that I can keep the
material up-to-date through articles like this or maybe with mailings to readers.
[Dan Weston's two book series, The Complete Book of Macintosh Assembly Language
Programming, Vol. 1 & 2, is a classic and one of the best of all Mac programming
books. We recommend it highly. Write to Dan care of MacTutor and we will forward
any comments to him. His books are published by Scott Foresman & Co. and available at
B. Dalton bookstores. -Ed]
Big Screens Have Big Prices
Anthony J. Oresteen
Batavia, IL
In recent months there have been numerous large screen monitors introduced for
the Macintosh. These include the Radius, Big Picture, MegaScreen II, ect. One thing in
common with these products is the big price. They all cost about $2000! Similar
screens are available for the IBM PC world at half the price, around $999 for screen,
PC card and support software. The Wyse WY-700 at 1200 x 800 is one that comes to
mind. Somehow I smell a snake here. What are Macintosh buyers getting for the extra
$1000? Perhaps we can learn a lesson from "hard disk" history. I'm waiting for the
price drop!
[The impact of the Mac II will make alternate screen technologies more
acceptable, driving up demand and competition, which will drive down the price. -Ed]
Referenced by (54):