Idiotproofing Your Keyboardby Jerry White
Please don't be offended by the word idiotproof. I use it innocently so as not to offend anyone by using the word foolproof. But seriously folks, using an INPUT command for keyboard input is not completely reliable, and can create problems.
Here's an example. You are playing a game with a friend. The game program has dimensioned strings and is now at an INPUT NAME$ command. Player #1 types his name and presses the RETURN key. So far, so good. As player #2 begins to enter his name, the first player discovers that he pressed a wrong key, and decides to make a correction. He interrupts player #2 and uses the CTRL-ARROW keys to reposition the cursor. Then he goes to delete a character using the CTRL-DELETE BACK S, and presses CTRL-CLEAR by mistake. What we have here is a problem.
One way to avoid this kihd of problem is to avoid using the INPUT command. You should replace it with a routine to examine each keystroke individually, and accept only the ones you need. In most cases, such a routine should not accept any CTRL characters, lowercase characters or inverse video. Writing this type of routine is not simple, so I'll save you considerable time and effart by sharing my idiotproofing routine with you.
The required subroutine begins at line 12, ends at line 28, and uses 440 bytes of RAM. At line 10, we issue the usual GRAPHICS 0 command and OPEN IOCB #1 for keyboard input. You may use a different IOCB number if you like, but be sure you also change the IOCB # in the GET command in line 18.
I did not disable the [BREAK] key in this demonstration program. This will be necessary, and can easily be done by inserting two pokes between the GRAPHICS 0 and OPEN commands. Insert POKE 16,64:POKE 53774,112.
The GOTO 30 at the end of line 10 neatly bypasses our subroutine and brings us to the introduction, which is followed by an input prompt. Note that this input prompt is not idiotproofed, so go ahead and clear the screen if you like. What we need here is the maximum length of the input as required by your program so that we can dimension our string accordingly.
For purposes of demonstration, you will now be asked to enter your name. But instead of using an input statement, we GOSUB 12.
The pokes in line 12 insure uppercase, normal video, and null any previously pressed keys. SP is used as a String Position counter.
At line 14 we store the last key pressed in the variable KEY, and loop until we get something acceptable.
At line 16 we check to see if our string position counter is 0, and if the last key pressed was [DELETE BACK SPACE]. If so, we go back to line 12.
At line 18 we have decided to accept the key, and store it as the variable AV by using a GET command. By doing this, we get the ASCII Value. In the same line, we must again check to see if we have the [DELETE] key, and skip ahead to line 26 if this is true.
At line 20 we check to see if we have the [RETURN] key or if the current string positian is at the maximum. In either case we print the return character, and RETURN or exit this subroutine.
At line 22 we add 1 to our counter, add the character to our string, and display the character on the screen. Don't forget that semicolon, because we want to stay on the current screen line.
At line 24 we go back to line 14 and wait for the next valid key to be pressed.
To refresh the human memory, back in line 18 we said that if we found the [DELETE] SP key, we should skip ahead to line 26. Here we check to see if your counter is equal to 1. If so, we will let the [DELETE] key perform its function, and start from scratch by going back to line 12.
The only way we will reach line 28 is if we have a [DELETE] and our counter is greater than 1. In this case we decrement the counter, make our string one position shorter, let [DELETE] do its thing, and go back to line 14.
That may seem like a lot of work just to avoid the remote possibility to certain keyboard input errors, but it's the price you have to pay for this type of human engneering. If you have a better way, please share it with us.