ST Outlook
Philip I. Nelson, Assistant EditorPointer Potpourri
Welcome to "ST Outlook." Beginning this month. I'm taking over COMPUTE!'s Atari ST column from Bill Wilkinson, who had agreed to do the column on an interim basis. By way of an introduction. I'm an ST owner and programmer, as well as a writer and editor. In addition to COMPUTE!'s ST Programmer's Guide, which I coauthored, I'm currently collaborating with COMPUTE! programmer Tim Victor on an upcoming book, Mapping the Atari ST, the first volume of which is scheduled for an early 1987 release.
Pick Your Pointer
Every ST owner is familiar with the way the mouse pointer changes appearance in response to system events. When you open an application from the desktop, or load a program from BASIC, the pointer changes from an arrow to a busy bee, and so on. In many situations, the ST manages the pointer shape automatically. But you can also change it under program control to suit your own needs.
This month's program shows how to access the ST's eight built-in pointer shapes from BASIC. It displays all the pointers in turn, prompting you to click the mouse button when you're ready to see the next one in the series. In addition to the familiar arrow and bee, you'll see two hand shapes, three different crosshair pointers, and a cursor shaped like a slender I-beam.
It's not difficult to see how alternate pointer shapes can come in handy. For instance, the bee does not automatically appear when you read or write to disk or perform other time-consuming chores in BASIC. While you can print the conventional PLEASE WAIT message under those circumstances, it's also prudent (and it adds a touch of elegance) to change the pointer to a bee. By reducing the user's temptation to fiddle with the menus or wave the pointer absent-mindedly, this little icon increases the chances that your program will work as intended. These cautions are doubly important because BASIC freezes program execution whenever the pointer is in motion and offers no easy means for disabling its own menus.
If you've used 1st Word, the word processor supplied with the ST, you may recognize the pointing hand, which appears whenever you drag the pointer to define a block of text. The I-beam cursor, thin enough to fit neatly between text characters, is ideally suited to word processing and similar applications. The grabbing hand pointer is often used to manipulate objects such as window sliders. And the crosshairs are ideal for drawing or any activity that requires precise positioning.
Suit Yourself
Of course, you're free to use these pointers as you please. The grabbing hand, for instance, is suitable for jobs that resemble grasping or pulling, but it works just fine as an eraser, too. One exception is our old friend, the bee, whose significance is already defined in clear and narrow terms. Unless you're writing software for apiarists, it's confusing (and, hence, lousy GEM etiquette) to use the bee shape to signify anything other than "busy."
In addition to the pointer-changing routine (labeled CHANGE) the program demonstrates VDI routines which read the mouse button, make the pointer invisible, and force it back onto the screen. The routine labeled CLICK calls VDI routine 124, which can read the pointer's screen coordinates as well as monitor button activity. To read the pointer's x and y coordinates, add this line to the program:
505 print "x=";peek(ptsout),"y=";peek(ptsout+2)
The subroutines HIDE and SHOW call VDI routines that disable and enable the mouse pointer, respectively. If you don't hide the pointer before you change its shape, it may misbehave, depositing an unwanted ghost image in some cases. Watch out for such unexpected side effects whenever you call a GEM routine from BASIC. It's fun to manipulate GEM artifacts such as the pointer, but with that added power comes an extra measure of responsibility.
The BASIC Difference
Calling GEM routines from BASIC is significantly different from using them in a language like C or Pascal. Some system routines are downright antagonistic to BASIC, others are a waste of time, and others are redundant. The first difference arises because BASIC is itself a GEM application—a large, complicated program with its own ideas about what should be happening at any given time. Certain GEM routines shouldn't be used because they conflict with BASIC'S own manipulation of the GEM environment.
The second category of routines includes those which do a job already performed by BASIC. For instance, since BASIC provides an output window, it's usually not necessary to open a virtual workstation or obtain a device handle before you call a system routine that draws on the screen. In the third category are routines that duplicate an existing BASIC command; why call a VDI routine to draw a circle, when CIRCLE is more convenient and achieves exactly the same result?
There's a fourth—fortunately, quite large—category of GEM routines: those which are both useful and usable from BASIC. In the months to come, we'll look at more of them.
100 fullw 2:clearw 2 110 for j=0 to 7 :rem Show all 8 pointers 120 gosub HIDE:gosub CHANGE:gotoxy 1,1 130 print:read shape$: print shape$ 140 print "Click left button to continue..." 150 gosub SHOW:gosub CLICK 160 next 170 gosub HIDE:rem Restore the arrow 180 j=0:gosub CHANGE 190 closew 2:gosub SHOW 200 end 210 HIDE: poke contrl,123:rem Hide pointer 220 vdisys(0):return 230 SHOW: poke contrl,122 :rem Show pointer 240 vdisys(0) :return 250 CHANGE: a#=gb:rem Key to Pandora's box 260 gintin=peek(a#+8):rem From me to AES 270 poke gintin,j :rem New mouse shape 280 gemsys(78): return 290 CLICK: poke contrl,124:rem Read mouse 300 vdisys(0) 310 if peek(intout)<>1 then CLICK 320 return 330 data Ye Olde Arrow,I-Beam Cursor 340 data Busy Bumblebee,"Pointing Hand " 350 data Grabbing Hand,Skinny Crosshair 360 data Chubby Crosshair,Hollow Crosshair