You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
PAGE 56<br />
the ASCII chart in them, usually in<br />
an appendix . We strongly<br />
recommend that you check out<br />
your own computer's ASCII.<br />
NUMBER, PAH-LEEZ.<br />
If line 300 had called for an<br />
address usually beginning with a<br />
number then we could use the<br />
same basic format as line 680<br />
changing the parameter values to<br />
reflect "O" as the lowest acceptable<br />
input and "9" as the highest:<br />
IF LEFT$ (IN$,1) => "O" AND<br />
LEFT$ (IN$, 1) = < "9" THEN<br />
GOTO NEXTPHRASE<br />
Naturally, you'd .change the<br />
subroutine to reflect that what's<br />
wanted is a number rather than a<br />
letter.<br />
It's easy to include exceptions in<br />
the line. Let's say that the address<br />
could begin with the word BOX, as<br />
in a post office box:<br />
IF LEFT$ (IN$, 3) = "BOX" OR<br />
(LEFT$ (IN$,1) = >"O" AND<br />
LEFT$ (IN$, 1) = "15" THEN<br />
GOTO REJECT<br />
The same format can be used for<br />
any range of individual characters<br />
or strings.<br />
The observant reader (you clever<br />
person, you!) will note that even in<br />
those cases where we want a<br />
number we use a string input.<br />
There are two basic reasons for this<br />
apparantly cavalier use of strings.<br />
First, strings are easier to<br />
manipulate. LEFT$-RIGHT$-MID$<br />
functions don't work on integers<br />
and reals, and these string<br />
functions are the most convenient<br />
ones in BASIC to use for error<br />
trapping. And secondly, many<br />
BASICs will give a HARD rejection<br />
FALL <strong>1980</strong><br />
if a non-numeric character is<br />
entered when a numeric variable is<br />
used to accept an input. That<br />
means, friend, that your program<br />
might crash and burn. A string<br />
variable, on the other hand, usually<br />
will accept anything.<br />
LEADING/TRAILING SPACES<br />
There is a negative side to this<br />
lack of discrimination on the part of<br />
string variables. Since they accept<br />
whatever is typed, they will accept<br />
inadvertant hits of the space bar.<br />
The string "gobble" is NOT the<br />
same as the string" gobble". When<br />
the computer looks at "gobble"<br />
the first thing it sees after the quote<br />
mark is ASCII 71 - what we see as a<br />
G. But when it looks at " gobble"<br />
the first thing it sees is ASCII 32, the<br />
space. That means that the name<br />
" Martha Mayno" will NEVER be<br />
found in a data base searching for<br />
"Martha Mayno". Goodness<br />
knows we don't want to lose poor<br />
Martha!<br />
Since the example we've been<br />
using is supposed to be part of a<br />
name and address data base, we're<br />
concerned<br />
about extraneous<br />
spaces. So we'll add the following<br />
lines:<br />
710 IF LEFT$ (IN$, 1) < > "<br />
"THEN 740<br />
720 IN$= RIGHT$ (IN$, LEN (IN$)<br />
- 1 )<br />
730 GOTO 710<br />
This code eliminates leading<br />
spaces from a string. It keeps on<br />
looping until all leading spaces are<br />
gone (just in case more than one<br />
got in). You'll also want to check for<br />
trailing spaces (since "Martha<br />
Mayno "will be lost forever) which<br />
can be done using similar code. The<br />
only real change is the substituting<br />
of BASIC's RIGHT$ function for<br />
LEFT$ (which works the same way,<br />
except backwards - see your<br />
BASIC manual for details). The<br />
following two lines of code are<br />
based on the way APPLESOFT<br />
handles the "truth" of IF-THEN<br />
statements: if the condition is false<br />
the program goes to the next line,<br />
as opposed to the next statement.<br />
Thus we can write:<br />
710 IF LEFT$(1N$, 1) =""THEN<br />
IN$ = RIGHT$ (IN$, LEN (IN$)<br />
- 1 ) :GOTO 710<br />
720 IF RIGHT$ (IN$, 1) =""THEN<br />
IN$ = LEFT$ (IN$, LEN (IN$) -<br />
1): GOTO 720