ADVERTISEMENT

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
parambytesSET  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
LEAscreenBits+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.

; xProcedureGetScreenSize(VAR r:Rect)
PEAtRect(A5); global scratch rect
JSRGetScreenSize
 
;Procedure  InsetRect(VAR r:Rect;dh,dv:INTEGER)
PEAtRect(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
PEAtRect(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
BSRInvalidScroll
 
; here is where we actually grow the window
; xProcedureGetScreenSize(VAR r:Rect)
PEAtRect(A5); global scratch rect
JSRGetScreenSize
 
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
PEAtRect(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

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]