by Steven Flintham (15A) Interacting with the user (5)
As mentioned in the last article, this
time I intend to cover some of the more
common ways of accepting user input,
concentrating on making them as user
friendly as possible. Inevitably, there
will be some overlap with comments I
have made in earlier articles, but I
hope that at least some of these
suggestions will be of use.
The points I intend to raise are of a
relatively trivial nature and you might
wonder why I have bothered to write the
article. However, in my opinion it is
these small details which add a final
professional finish to a program and
are often overlooked.
When requesting a single character
input, you should consider carefully
whether or not to accept the input
without confirmation. For instance, in
the menus earlier in this series the
quick keys did not act immediately - it
was necessary to press RETURN
afterwards. This has the advantage that
it reduces the chances of an accidental
keypress causing problems, but it also
slows down the use of the program and
could cause irritation if many such
options are used.
There is no correct method - you should
consider each situation individually
and bear in mind the possible
consequences of the action. However,
when you are asking for confirmation of
another action, such as a "Confirm?
(Y/N)" prompt as part of a routine, it
may be over cautious to require a
RETURN after pressing Y or N.
However you are accepting an input, you
should use *FX21 to flush the keyboard
buffer unless there is a particular
reason not to do so. This is
particularly important when using a
single key input because a keypress
which is left sitting in the keyboard
buffer may well be accepted and cause
confusion and/or damage.
When accepting a string, you should not
generally use INPUT or INPUT LINE.
These allow the input of, among other
things, control codes and so your
program could easily be crashed by the
user, either maliciously or by
accidental use of the CTRL key.
Perhaps the most devastating possiblity
is for CTRL-V followed by (for
instance) CTRL-@ to be entered - this
will change to screen mode 0 and will
almost certainly completely ruin the
screen display. If you are running in a
non-shadow mode which requires less
than the new mode, the effect could be
much more serious as this may well
result in loss of variables and/or part
of the program.
INPUT and INPUT LINE also do not allow
control over the length of string
entered, so it is perfectly possible
for the user to enter 255 characters
and cause the screen or text window to
scroll, creating obvious problems with
screen layout.
All of these problems can be avoided by
using a purpose-written routine which
accepts characters using GET or GET$,
examines them to eliminate unacceptable
input and builds up a string ready for
use. This is most easily done with a
function, as demonstrated in the
accompanying program Input. The
function (FNinput) should be fairly
easy to follow, so no explanation will
be given - in any case, you do not need
to know how it works to use it in your
own programs. It should be called using
FNinput(max%,null%) where max% is the
maximum length of the string and null%
is either TRUE or FALSE and specifies
whether or not an empty (null) string
is acceptable. Setting null% to FALSE
will result in the function not
returning until there is at least one
character in the string to be returned.
Try changing the call to the function
in the demonstration program to see the
effect.
As with all the other routines given in
this series, you are free to use
FNinput in your own programs provided
it is not used for profit. I think I
may have covered this form of input in
a previous article, but I have had a
quick look through my back issues of
8BS and cannot find it. However, if I
have repeated myself, I apologise.