Skip to main content

 "Q: What were you in civilian life?"
 "A: Happy, sir!"


                YOUR SECOND GFA BASIC 3.XX MANUAL
                             - or -
        HOW I LEARNED TO STOP WORRYING AND LOVE GFA-BASIC
                             PART 15
                    CHAPTER FOURTEEN - MOUSE
                          by Han Kempen

Editor

 Sometimes  the  editor  seems  to freeze  while  the  cursor  is
blinking rapidly.  Just move the mouse and the editor comes alive
again.

Fileselector

 Sometimes  the  same blinking mouse appears  after  calling  the
Fileselector or an Alert-box.  I've read somewhere this could  be
due  to the combination of a VDI-function (for the mouse) and  an
AES-function (for Fileselector or Alert-box).  GFA takes care  of
the  first  and GEM of the second,  and sometimes this  seems  to
result in a conflict.

MOUSE

 If  you  repeatedly  call a Procedure in which you  test  for  a
mouse-click  (with  MOUSE or MOUSEK),  you should  incorporate  a
short  pause  in the Procedure  (e.g.  PAUSE  5).  Otherwise  the
Procedure  might be called again while the user is still  holding
the button down.  You could also wait until the user releases the
button:

     REPEAT
     UNTIL MOUSEK=0      ! wait until button is released

 If you find it difficult to move the mouse accurately, you could
use  <Shift>  <Alternate> <Arrow> to move  the  mouse-cursor  one
pixel  in the desired direction.  If you press <Insert> as  well,
you  can 'drag' something accurately as if the left  mouse-button
was  pressed.  You  can simulate several mouse-actions  with  the
keyboard:

     <Alt><Arrow>                   - move mouse-cursor 16 pixels
     <Shift><Alt><Arrow>            - move 1 pixel
     <Alt><Insert>                  - click left button
     <Alt><ClrHome>                 - click right button
     <Alt><Insert><Arrow>           - hold left button down and
                                          move (16)
     <Shift><Alt><Insert><Arrow>    - hold left button down and
                                          move (1)
     <Alt><ClrHome><Arrow>          - hold right button down and
                                          move (16)
     <Shift><Alt><ClrHome><Arrow>   - hold right button down and
                                          move (1)

 You can find the maximal x- and y-coordinates of the mouse with:

     x=DPEEK(&H9862)
     y=DPEEK(&H9864)

 But  there's  no guaranty you will find the  coordinates  there.
Experiment with XBIOS 0 for a more reliable method.  Don't ask me
how (this method will only work on one specific TOS  version,  as
it uses undocumented system variables, ED.).

 MOUSE  returns negative coordinates if the mouse is to the  left
of  or  above  the current window (or the origin  that  has  been
selected with CLIP OFFSET).

 If  the  mouse is visible (SHOWM) and you put something  on  the
screen (e.g.  with PRINT or PUT),  the mouse is turned  off.  The
advantage  is that you can't destroy the screen under the  mouse-
cursor. The disadvantage is that you could see a rapidly blinking
mouse if you repeatedly put something on the screen. The cure for
this problem is to wait until the user actually moves the  mouse,
but  then  the mouse will still flicker during  movement  of  the
mouse.  The  cure for that problem is to wait until the mouse  is
stationary again. Now there will be no flickering at all:

     SHOWM
     MOUSE x1,y1,k            ! where is the mouse now?
     REPEAT
       MOUSE x,y,k
     UNTIL x1<>x OR y1<>y     ! wait until mouse is moved
     REPEAT
       x1=x
       y1=y
       PAUSE 1
       MOUSE x,y,k
     UNTIL x1=x AND y1=y      ! wait until mouse is stationary
                                 again

SETMOUSE

 A mouseclick can be simulated with:

     SETMOUSE mx,my,mk

 If you try this with an Alert-button you have to move the  mouse
after-wards,  or the button won't be selected.  I don't know why,
so I can't tell if this is a bug.

 If  you use SETMOUSE before ALERT,  you won't be able to  choose
the  default ALERT-button with <Return>.  Sometimes it  helps  to
insert this before ALERT:

     REPEAT
     UNTIL MOUSEK=0

 But this doesn't help always. I do know it's impossible to use a
default-button in those cases, but I have no idea why.

HIDEM

 Although the mouse-cursor is invisible after HIDEM, the mouse is
still monitored by the operating system. If you move the mouse it
will  take  time to process the movement and this will  slow  the
program  down.  You  could prevent that by  switching  the  mouse
temporarily off:

     OUT 4,18       ! disable mouse
     (...)          ! mouse can't disturb us here
     OUT 4,8        ! activate mouse again

 Disabling  the  mouse will not result in  your  program  running
faster, except when a nervous user keeps moving the mouse all the
time.

DEFMOUSE

 In  a  compiled  program it's a good idea to  use  'DEFMOUSE  0'
(arrow)  because GEM leaves the bee behind as  the  mouse-cursor.
GEM  also  switches  the mouse-cursor off,  so you  have  to  use
'SHOWM'  if  you  need a visible mouse-cursor  in  your  compiled
program.

 After  FILESELECT  or ALERT the mouse-cursor is changed  to  the
default-arrow.  Use  DEFMOUSE (again) if you need another  cursor
after FILESELECT or ALERT.

 You  can  use  one of the many Public  Domain  mouse-editors  to
design your own mouse-mutant.  But it's also easy to create a new
mouse-cursor in your GFA-program:

     ' Construct mouse-string (37 words) from data in DATA-lines
     RESTORE pattern.mouse
     m$=STRING$(74,0)                           ! prevent garbage
     READ x,y,mode,msk.color,mouse.color
     MID$(m$,1,2)=MKI$(x)                          ! word 1
     MID$(m$,3,2)=MKI$(y)                          ! word 2
     MID$(m$,5,2)=MKI$(mode)                       ! word 3
     MID$(m$,7,2)=MKI$(msk.color)                  ! word 4
     MID$(m$,9,2)=MKI$(mouse.color)                ! word 5
     FOR n=1 TO 16                                 ! word 6-21
       READ msk$
       MID$(m$,9+n*2,2)=MKI$(VAL("&X"+msk$))
     NEXT n
     FOR n=1 TO 16                                 ! word 22-37
       READ mouse$
       MID$(m$,41+n*2,2)=MKI$(VAL("&X"+mouse$))
     NEXT n
     '
     DEFMOUSE m$                            ! activate new mouse
     '
     pattern.mouse:
     ' x,y,mode(0=normal;1=XOR),mask-colour,mouse-colour
     DATA 0,0,0,0,1
     '
     ' mask-pattern (1 = pixel on , 0 = pixel off)
     DATA 0000111111110000
     DATA 0001111111111000
     DATA 0011111111111100
     DATA 0111111111111110
     DATA 0111111111111110
     DATA 0111111111111110
     DATA 0111111111111110
     DATA 1111111111111111
     DATA 1111111111111111
     DATA 1111111111111111
     DATA 0111111111111110
     DATA 0111111111111110
     DATA 0111111111111110
     DATA 0011111111111100
     DATA 0001111111111000
     DATA 0000111111110000
     '
     ' mouse-pattern (1 = pixel on , 0 = pixel off)
     DATA 0000000000000000
     DATA 0000111111110000
     DATA 0001111111111000
     DATA 0011111111111100
     DATA 0010000000000100
     DATA 0010011001100100
     DATA 0010000100000100
     DATA 0110001000000110
     DATA 0110010000000110
     DATA 0110011110000110
     DATA 0010000000000100
     DATA 0010100000010100
     DATA 0010011111100100
     DATA 0001000000001000
     DATA 0000111111110000
     DATA 0000000000000000

 The  mask  should be an exact copy of the mouse-pattern  if  you
need  a transparant mouse-cursor,  although the cursor will  look
better  if the mask is one pixel larger than the outline  of  the
mouse-pattern.  Leave the mask empty (all '0') and the mouse will
disappear  behind objects on the screen.  Fill the mask with  '1'
and the 16x16 mouse will always remain visible.  Switch mask- and
mouse-colour in the first DATA-line to create a 'reverse'  mouse.
Or  use  any VDI colour-index that is available  in  the  current
resolution.

 A  strange  phenomenon  (also called a bug) occurs  if  you  use
DEFMOUSE  while the mouse-cursor is at the top of the screen  and
you click the left button.  The program freezes,  but if you move
the mouse-cursor down the screen the program continues  normally.
This  happens if the mouse is located in the "menu-part"  of  the
screen (0 ? y ? 18),  even if there is no menu.  I could  pretend
that  I  know  exactly  what is happening  by  stating  that  GFA
probably  uses  Graf_mkstate  (GEMSYS 79)  and  this  causes  the
problem. Actually I have no idea what's going on.

                     Procedures (CHAPTER.14)

Mouse_action                                             MOUS_ACT
 Wait until the user moves the mouse:
     @mouse_action(FALSE,x,y,k)
 Mouse-coordinates and button-state are returned.  If the flag is
TRUE  the  Procedure waits until the mouse  is  stationary  again
before  returning  the  coordinates.  A  button-press  is  always
returned immediately.

Mouse_init_1 and Mouse_create                            MOUSINIT
 Create  a new mouse-cursor (mask and mouse are stored  in  DATA-
lines):
     @mouse_init_1(mouse$)
     DEFMOUSE mouse$
 Other  cursors could be stored in  other  Mouse_init-Procedures.
The  actual  construction  of the  mouse-string  takes  place  in
Procedure Mouse_create.

Mouse                                                       MOUSE
 Disable mouse temporarily:
     @mouse(FALSE)     ! disable mouse
     (...)             ! playing with the mouse doesn't slow
                          program down
     @mouse(TRUE)      ! activate mouse again 

Disclaimer
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.