Updating Windows in Basic

By Dave Kelly, MacTutor Editorial Board

A fresh window lets you see things more clearly. (I like mine in color, but black & white mode on the Macintosh II sure is faster). I received the following request from one of our readers which I’m sure others of you would also like to know about:

Q. I am working on an application in ZBasic 4.00 that I hope to release commercially. Previously I never had to worry about handling update events in a “correct” manner (in the past I have always reprinted everything on the screen when I’ve encountered an update event). ZBasic does provide a WINDOW PICTURE statement that I have not gotten to work to my satisfaction. I have also tried GET and PUT without much success. I’m obviously doing something wrong. could you show various ways to handle update events that involve DAs and multiple windows? My application has Edit Fields and displayed text (i.e. displaying results obtained from values entered in the edit fields).

A. Yes, there can be some tricky problems associated with refreshing windows which use edit fields. There is a standard way that refreshing should work. In Pascal the application should respond by calling BeginUpdate, drawing the window, then call EndUpdate. The Window Manager section of Inside Macintosh explains how to do this. That’s fine when using the Macintosh standard GetNextEvent loop, but in ZBasic the approach must be modified.

The object is to restore any window which gets covered up by another window. If window 1 is dragged over window 2, then if window 2 is selected it should automatically be redrawn. Or if only part of window 2 is covered up and window 1 is removed then window 2 should be refreshed. This means that you as a programmer are responsible to determine all of the possible ways the window could be erased and be sure to set up event handling to cover all the possibilities.

There are 3 options we have for screen refresh with ZBasic.

1. Redraw the picture in response to a DIALOG event.

2. Use the WINDOW PICTURE statement.

3. Use GET and PUT in response to a DIALOG event.

By the end of this discussion you will know when to use each method in different circumstances. Directly redrawing the window is probably used most often by those that don’t know about the other two methods (or don’t know how they work). Redrawing is what I think of as the “brute force” method. It is usually the method used for “quick and dirty” screen refresh. The advantage is that you have control to force the update to occur whenever you feel like it. The disadvantage is that it is slower and you may find that the screen may get updated sometimes when it doesn’t need it (in order to catch every possible event).

Fig. 1 Our Multiple Window Example

To refresh by redrawing in the “brute force” mode a DIALOG(0)=5 event should effectively determine when a window needs to be refreshed. The window that needs to be refreshed is returned in the DIALOG(5) function. A quick call to the screen drawing routine when DIALOG event occurs is all that is needed to make this work.

The 2nd method of refreshing the screen is somewhat unique to ZBasic. Using the WINDOW PICTURE statement is the most automatic way to update the screen. A good example of using WINDOW PICTURE is given in the ZBasic manual on page E-158. The example at the end of this column also demonstrates its use. There are a few problems which you should be aware of. When using WINDOW PICTURE, all DIALOG events for the window involved are not passed to the DIALOG function, but instead are automatically handled by the WINDOW PICTURE statement. This is both good and bad. It is good because now any portion of the screen can be refreshed automatically without really trying. The problem comes when you use an EDIT FIELD in the window which you are using WINDOW PICTURE. When WINDOW PICTURE is active, the EDIT FIELD is not updated properly. Ordinarily the EDIT FIELD is automatically updated, but not with WINDOW PICTURE. This is one of those cases where the window should be refreshed with the “brute force” method. The process can be improved by setting up the screen information to be updated in a PICTURE so that it can be redrawn quickly. The demo shows how this is done. The “Set Window 1 Update” routine is called whenever an update event occurs. Also the EDIT FIELD value is re-read and the text displayed is obtained from the current contents of the EDIT FIELD. It is really too bad that in ZBasic the WINDOW PICTURE statement doesn’t update controls. [My guess is that WINDOW PICTURE is nothing more than the automatic window updating procedure of placing a quickdraw picture handle in the window record’s pic field, in which case, no controls or edit fields would be updated. This method was only intended for fairly static window contents, and never meant to be a true update procedure for dynamic windows. -Ed]

To use WINDOW PICTURE you first define the PICTURE which you want to print. This can be a combination of text and graphics. The PICTURE is pointed to by a variable which is used in the WINDOW PICTURE statement to initialize the automatic update routine. To stop the update or to modify it you can use WINDOW PICTURE #1,0 (if using window #1) and then KILL PICTURE to delete the picture from memory. If you don’t remove the pictures from memory, they may use up some of your memory and sooner or later if enough pictures are used, you could run out of memory.

I think the 3rd method is a bit more cumbersome than the first two. I call it the “GET/PUT” method. First, the window contents are drawn for the first time. Then the rectangle containing the contents of the window must be determined exactly. These coordinates are plugged in to an equation given on page 232 of the ZBasic manual. The equation determines the number of bytes to use in a DIM statement for the graphic image used in the GET and PUT statement. The equation is:

bytes = 6 + ((y2-y1)+1) * ((x2-x1)+1) * bpp + 7) / 8

where x1, y1 are the coordinates of the upper-left-corner of the graphic image on the screen; x2, y2 are the coordinates of the lower-right-corner of the image. The bits-per-pixel, bpp, depends on your Macintosh screen setup. Standard black & white Macintoshes have one bit per pixel, a Macintosh II with sixteen colors is 4 bpp and 256 colors is 8 bpp. Now divide the number of bytes by two for the integer (16 bit) array used in the DIM statement. This is the extent of the difficulty in using the “GET/PUT” method. The DIM statement should be executed only once at the beginning of your program and enough space should be allocated for whatever you plan to update. After the screen is drawn the first time, the GET statement is used to set the array to the screen image. If your array isn’t dimensioned big enough you can definitely expect a system bomb here. I would recommend that you only use the “GET/PUT” method when you are not going to change the window contents. The PUT statement is called by the DIALOG event routine whenever the window needs refreshing. (Mac II color users, notice that the PUT statement only refreshes in black & white; the color information is ignored. This is unfortunate. Maybe in a future release of ZBasic with 256 color support?????).

The demo program demonstrates the three methods discussed above. Try opening DAs and dragging a window on top of other windows and closing/opening them. I feel that this program should give you a good idea of how windows can be refreshed. I strongly recommend that most of your refreshing be done with the WINDOW PICTURE statement whenever possible. (NOTE: ‘whenever possible’ is just about always, except when controls are used on the same screen. Maybe this will get fixed someday too so that WINDOW PICTURE will work when EDIT FIELDs are active).

This has been a much more pleasant program to write as Zedcor has released version 4.01 with a much improved editor. The editor isn’t perfect, but if you remember to save your program often enough you can get by without exiting ZBasic. Also, they have added DIALOG(0)=17 for disk inserts. DIALOG(17) returns the disk drive which the disk was inserted. ZBasic is still the best Basic available today and keeps looking better each new release. Zedcor, keep up the good work.

Zedcor and True Basic have announced new versions at the San Francisco Expo. Watch for details on these new products. -Ed

‘ WINDOW UPDATE DEMO
‘ ©1988 MacTutor®
‘ By Dave Kelly

WINDOW OFF
COORDINATE WINDOW
DEF MOUSE=-1
DIM Wptr&(3)

APPLE MENU “About Updating ”
MENU 1,0,1,”File”
MENU 1,1,1,”Quit”
EDIT MENU 2
MENU 3,0,1,”Window”
MENU 3,1,1,”Show Window 1"
MENU 3,2,1,”Show Window 2"
MENU 3,3,1,”Show Window 3"
MENU 3,4,1,”Show All Windows”

‘Find out monitor size just in case we need it
CALL GETWMGRPORT(WMgrPort&)
PortTop=PEEK WORD(WMgrPort&+8)
PortLeft=PEEK WORD(WMgrPort&+10)
PortBottom=PEEK WORD(WMgrPort&+12)
PortRight=PEEK WORD(WMgrPort&+14)

WINDOW#1,”Window 1",(PortLeft+4,PortTop+42)-(300,300),5
Wptr&(1)=WINDOW(14)
TEXT 3,12
EDIT FIELD 1,”Read MacTutor!”,(50,200)-(270,225),1
GOSUB “Set Window 1 Update”

WINDOW#2,”Window 2",(PortLeft+24,PortTop+62)-(320,320),5
Wptr&(2)=WINDOW(14)
‘NOW... Create the picture for the first window
PICTURE ON
TEXT 2,24,1
COLOR=4
PRINT@(3,1)”MacTutor®”
COLOR=7
TEXT 3,12,0
PRINT@(6,4)”The Best in the West!”
PRINT@(5,6)”This is the second window”
PICTURE OFF,Pic2&
PICTURE, Pic2&:’ Draw the picture
WINDOW PICTURE #2,Pic2&

WINDOW#3,”Window 3",(PortLeft+44,PortTop+82)-(340,340),5
Wptr&(3)=WINDOW(14)
x1=0:x2=300:y1=0:y2=300
‘ bytes used = 6 + ((y2-y1)+1) * ((x2-x1+1)* bpp + 7) / 8)
DIM Pic3%(58293) :’ space for 32 bits-per-pixel (MAC II)
‘ NOW... Create the picture for the third window
TEXT 2,24,1
COLOR=4
PRINT@(3,1)”MacTutor®”
COLOR=7
TEXT 3,12,0
PRINT@(6,4)”The Best in the West!”
PRINT@(5,6)”This is the third window”
GET (x1,y1)-(x2,y2),Pic3%(1)
PUT (0,0),Pic3%(1),0

ON DIALOG GOSUB “DialogEvent”
ON MENU GOSUB “MenuEvent”
FLUSHEVENTS
MENU ON:DIALOG ON

“Loop”
GOTO “Loop”
MENU OFF:DIALOG OFF

“DialogEvent”
D=DIALOG(0)
SELECT D
 CASE 3
 WINDOW DIALOG(3)
 CASE 4
 CALL HIDEWINDOW(Wptr&(DIALOG(4)))
 CASE 5,6,7
 IF DIALOG(5)=3 THEN GOSUB”Window3 Update” ELSE GOSUB “Set Window 1 Update”
END SELECT
RETURN

“MenuEvent”
Menunumber=MENU(0)
Menuitem=MENU(1)
MENU
SELECT Menunumber
 CASE 255
 GOSUB “AppleMenu”
 CASE 1
 GOSUB “FileMenu”
 CASE 3
 GOSUB “WindowMenu”
END SELECT
RETURN

“AppleMenu”
WINDOW 4,””,(100,100)-(400,250),-2
PICTURE ON
TEXT 0,12,0,0
PRINT @(2,2) “(ZBASIC) Window Update Demo V1.0”
PRINT @(10,3)”by”
PRINT @(8,4)”Dave Kelly”
COLOR=6
PRINT @(7,6)”©MacTutor, 1988"
COLOR=7
PRINT @(7,7)”ZBasic version 4.01"
PICTURE OFF,Pic4&
PICTURE ,Pic4&
WINDOW PICTURE #4,Pic4&
MOUSE ON
DO
mous=MOUSE(0)
outsiderect=(MOUSE(1)<0 OR MOUSE(1)>300 OR MOUSE(2)<0 OR MOUSE(2)>150)
IF MOUSE(1)=0 AND MOUSE(2)=0 THEN “Stop”
UNTIL mous<>0 AND NOT (outsiderect)
MOUSE OFF
KILL PICTURE Pic4&:’ Delete the picture from memory
DIALOG ON
WINDOW CLOSE 4
DIALOG OFF
RETURN

“Window3 Update”
ActiveWindow=WINDOW(0)
WINDOW OUTPUT 3
PUT (0,0),Pic3%(1),0
WINDOW OUTPUT ActiveWindow
RETURN

“Set Window 1 Update”
ActiveWindow=WINDOW(0)
WINDOW OUTPUT 1
‘NOW... Create the picture for the first window
 KILL PICTURE Pic1&
 PICTURE ON
 TEXT 2,24,1
 COLOR=4
 PRINT@(3,1)”MacTutor®”
 COLOR=7
 TEXT 3,12,0,0
 PRINT@(6,4)”The Best in the West!”
 PRINT@(5,6)”This is the first window”
 Editvariable$=EDIT$(1)
 PRINT@(5,8)”The edit field = “;Editvariable$
 PICTURE OFF,Pic1&
PRINT@(5,8);SPC(100)
PICTURE, Pic1&:’ Draw the picture
WINDOW OUTPUT ActiveWindow
RETURN

“FileMenu”
IF Menuitem=1 THEN “Stop”
RETURN

“WindowMenu”
SELECT Menuitem
 CASE 1
 CALL SHOWWINDOW(Wptr&(1)):WINDOW 1
 CASE 2
 CALL SHOWWINDOW(Wptr&(2)):WINDOW 2
 CASE 3
 CALL SHOWWINDOW(Wptr&(3)):WINDOW 3
 CASE 4
 FOR i=1 TO 3
 CALL SHOWWINDOW(Wptr&(i))
 WINDOW i
 NEXT i
END SELECT
RETURN

“Stop”
WINDOW PICTURE #1,0:’Don’t update the first window anymore
KILL PICTURE Pic1&:’ Delete the picture from memory
WINDOW PICTURE #2,0:’Don’t update the second window anymore
KILL PICTURE Pic2&:’ Delete the picture from memory
END