"By working faithfully eight hours a day you may eventually get
to be a boss and work 12 hours a day."
YOUR SECOND GFA BASIC 3.XX MANUAL
- or -
HOW I LEARNED TO STOP WORRYING AND LOVE GFA-BASIC
CHAPTER SEVENTEEN - PROGRAM DECISIONS
by Han Kempen
IF ... ENDIF
If the value of a certain variable must fall in the range min%-
max%, you could program that as follows using IF ... ENDIF:
ELSE IF n%<min%
In this case you could also use MAX and MIN:
You probably test for two conditions by using AND:
IF cond1! AND cond2!
(...) ! both true
But separate testing is much faster:
(...) ! both true
Multiple 'IF ... ENDIF' tests that are mutually exclusive could
be replaced by 'ELSE IF' tests:
ELSE IF cond2!
ELSE IF cond3!
ELSE IF cond4!
ELSE IF cond5!
Now if one of the tests is TRUE, the following tests will be
skipped. If you use multiple 'IF ... ENDIF' tests, all conditions
will always be tested.
ON ... GOSUB
It's important to understand when no Procedure is called in an
ON .. GOSUB line, e.g.:
ON p GOSUB p_1,p_2 ! Procedures always without parameters
In this case variable p determines what happens as follows:
p = 0 - no Procedure is called
1 ? p < 2 - Procedure p_1 is called
2 ? p < 3 - Procedure p_2 is called
p ? 3 - no Procedure is called
Multiple 'ELSE IF' constructions can sometimes be replaced by
At each CASE you can use integers, strings or integer-variables
(byte|, word& or integer%) but not string-variables. Only the
first four bytes of a string can be used. The editor will not
accept something like CASE "test2", only CASE "test".
If you use SELECT in a loop, you can exit the loop as follows:
CASE CHR$(27) ! user pressed <Esc>
EXIT IF TRUE ! exit the loop
In a compiled program, the code between SELECT and ENDSELECT
must not exceed 32K or the program will jump to the wrong CASEs.
Actually it's more likely that you will be struck by lightning
than that you'll ever encounter this bug. Programmers using more
than 32K between SELECT and ENDSELECT obviously must have been
struck by lightning (or something else) already. If the
discoverer of this bug is reading this, I apologize sincerely.
Let's hope he or she will not be struck by lightning again.
Try the following listing:
PRINT "empty string"
PRINT "a string"
If you press <Return> immediately, you enter the null-string.
This is properly recognized in an interpreted program, but a
compiled program runs amok. The null-string is not recognized and
strange things happen afterwards, including showing a couple of
bombs after you pressed "q".
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.