"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
CHAPTER FOURTEEN - MOUSE
by Han Kempen
Sometimes the editor seems to freeze while the cursor is
blinking rapidly. Just move the mouse and the editor comes alive
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.
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
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
<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
<Shift><Alt><Insert><Arrow> - hold left button down and
<Alt><ClrHome><Arrow> - hold right button down and
<Shift><Alt><ClrHome><Arrow> - hold right button down and
You can find the maximal x- and y-coordinates of the mouse with:
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:
MOUSE x1,y1,k ! where is the mouse now?
UNTIL x1<>x OR y1<>y ! wait until mouse is moved
UNTIL x1=x AND y1=y ! wait until mouse is stationary
A mouseclick can be simulated with:
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:
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.
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
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
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
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
m$=STRING$(74,0) ! prevent garbage
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
FOR n=1 TO 16 ! word 22-37
DEFMOUSE m$ ! activate new mouse
' mask-pattern (1 = pixel on , 0 = pixel off)
' mouse-pattern (1 = pixel on , 0 = pixel off)
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
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.
Wait until the user moves the mouse:
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
Mouse_init_1 and Mouse_create MOUSINIT
Create a new mouse-cursor (mask and mouse are stored in DATA-
Other cursors could be stored in other Mouse_init-Procedures.
The actual construction of the mouse-string takes place in
Disable mouse temporarily:
@mouse(FALSE) ! disable mouse
(...) ! playing with the mouse doesn't slow
@mouse(TRUE) ! activate mouse again
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.