| 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 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
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]
