USE CURSOR KEYS TO SCROLL TEXT. USE CURSOR KEYS TO SCROLL TEXT. Creating user friendly programs Creating user friendly programs Part 8 Part 8 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.