SKYHAWKE EX. 1016, page 2
`
`

`
`SKYHAWKE EX. 1016, page 3
`
`

`
`COMPUTER SCIENCE TEXTS
`
`Man—Computer Interfaces
`
`R. B. COATS
`and
`I. VLAEMINKE
`Both Principal Lecturers
`in Computing
`Leicester Polytechnic
`
`BLACKWELL SCIENTIFIC PUBLICATIONS
`OXFORD LONDON EDINBURGH
`
`BOSTON PALO ALTO MELBOURNE
`
`

`
`0 1987 by
`Blackwell Scientific Publications
`Editorial offices:
`Osney Mead, Oxford OX2 OEL
`(Orders: Tel. 0865 240201)
`8 John Street, London WCIN H35
`23 Ainslie Place, Edinburgh EH3 6A1
`52 Beacon Street, Boston
`Massachusetts 02108, USA
`667 Lytton Avenue, Palo Alto
`California 9430I, USA
`107 Barry Street, Carlton
`Victoria 3053, Australia
`
`All rights reserved. No part of this
`publication may be reproduced, stored
`in a retrieval system, or transmitted, in
`any form, or by any means, electronic,
`mechanical, photocopying, recording
`or otherwise without the prior
`permission of the copyright owner.
`First published 1987
`
`Set by V & M Graphics Ltd,
`Aylabury, Bucks
`Printed and bound in Great Britain by
`Mackays of Chatham, Kent
`
`DISTRIBUTORS
`
`USA and Canada
`Blackwell Scientific Publications Inc
`PO Box 50009, Palo Alto
`California 94303
`(Orders: Tel. (415) 965-4081)
`Australia
`Blackwell Scientific Publications
`(Australia) Pty Ltd
`107 Barry Street
`Carlton, Victoria 3053
`(Orders: Tel. (03) 347 0300)
`
`British Library
`Cataloguing in Publication Data
`Coats, R. B.
`Man-computer interfaces: an
`introduction to software design
`and implementation.
`1. Computer interfaces
`1. Title
`II. Vlaeminke, I,
`004.6
`TK7887.5
`
`ISBN 0—632—0l542—X
`
`Library of Congress
`Coats, Robert B.
`Man—computer interfaces: an
`introduction to software design and
`implementation/R. B. Coats & I.
`Vlaeminke.
`Includes index.
`ISBN 0-632—OI542—X
`1. Computer software-
`Development.
`2. Electronic
`data processing-—Psychological
`aspects.
`3. System design.
`I. Vlaeminke, I.
`II. Title
`1987
`QA76.76.D47C63
`005—dcI9
`87-16110
`
`

`
`Chapter 3
`
`Input/output processes
`
`3.1 Introduction
`
`In Chapter 2, the messages exchanged between a user and the system were
`classified in terms of the functions they performed within the dialogue. In this
`chapter, we concentrate on how the nature of the information exchanged
`impinges on software design. For this purpose we classify the basic input/
`output processes which support these message functions into the categories of
`Fig. 3.1.
`Output of a text masage
`at the current postition on the device
`at a particular position on the device
`with particular format attributes
`Input of a text message
`using standard high level input routines
`character-by-character
`where ‘special characters’ are involved
`Input of a Point and Pick message
`relative pointing to scroll round a list
`absolute pointing anywhere on the device
`Output of a graphical message
`Input of a graphical message
`Fig. 3.1. A classification of common input and output processes.
`
`A text message is defined as a string of characters; these characters may be
`upper or lower case alphabetics, numerals, or even the basic graphics
`characters (such as playing card suit symbols) available as alternate character
`sets on many microcomputers. A graphical message is defined as a message
`which cannot be represented as a string of characters; typically it must be
`described at the ‘bit’ rather than at the ‘character’ level. Point and pick is a
`special case of an input message for selecting from a set of possible options;
`as we shall see, it has characteristics which deserve individual treatment.
`The simple dialogue examples in Chapter 2 utilise the standard PASCAL
`input and output procedures for the input/output processes. In this chapter
`
`37
`
`

`
`38
`
`Chapter 3
`
`we consider other features which are available to enhance these processes.
`These features have typically been considered in terms of the processing
`required to effect them on a particular device. However, we also saw in
`Chapter 2 that the dialogue process deals with logical entities and should be
`separated from the precise mechanics of a particular device. Therefore, whilst
`considering how the features can be effected, we will attempt to develop
`generalised ‘abstractions’ for the processes which the dialogue process can
`assume.
`
`3.2 Output of a Text Message
`
`3.2.1 Output of Text at the Current Position of the Device
`
`My Message Displayed Here
`
`Fig. 3.2.
`
`An output text message, like that illustrated in Fig. 3.2, can be specified by
`defining:
`
`what is to be output, i.e. a string ofcharacters identifying the content of the
`message;
`
`where it is to be output, i.e. the position on the output device;
`how it is to be output, i.e. a list of attributes, such as colour, which define
`how the content is to be formatted; we will assume that the attributes are
`constant for a given message.
`We define an output message as an entity which is represented by a data
`structure of type:
`
`OutputMessageType = record
`
`: string;
`content
`: SlotType;
`slot
`attributes : AttributesType;
`end;
`
`{what}
`{where}
`{how}
`
`Content is of type ‘string’ by virtue of our definition of a text message.
`
`

`
`Input/output processes
`
`39
`
`However, the definitions of SlotType and AttributesType require further
`consideration.
`The most common input/output device in the early days of interactive
`computing was the teletype, which resembles a golfball typewriter. A teletype
`only provides the facility to output the message content at the current position
`of the device; the current position can be advanced to a new line by the output
`of suitable control characters. Most programming languages contain proce-
`dures for teletype operation.
`The WRITE and WRITELN statements of PASCAL operate in this way;
`thus,
`
`write (‘write this without advancing to a new line’)
`
`displays the specified character string and leaves the output device positioned
`at the next character position and
`
`writeln (‘write this and skip to a new line’)
`
`displays the character string and positions the output device at the first
`character position on the next line.
`The teletype has largely been superseded by the Visual Display Terminal
`(VDT) consisting of a monochrome or colour display and keyboard. Early
`VDTs operated merely as ‘glass teletypes’ with the same line scrolling mode.
`Nowadays, the vast majority provide page mode operation, in which the
`output can be considered a screen at a time rather than a line at a time; a
`message can be written at any position on the screen.
`We will concentrate on output to a screen since it is the most common
`device; similar considerations apply for a printer. The basic approach is also
`appropriate for other output devices, such as a speech synthesiser, although
`the features will obviously differ.
`
`3.2.2 Output of Text at a Particular Position on the Device
`
`The text of an output message is displayed in a slot — a rectangular area on
`the device w character positions wide and h character positions high. There
`are three possible cases, as shown in Fig. 3.3. Thus, the Slot can be defined by
`a data structure of type
`
`

`
`[:::l
`
`character
`position
`w=h=l
`D
`
`byte
`SlotType
`
`= 0..255;
`record
`row,co1
`width,height
`end;
`
`: byte;
`: byte;
`
`{startingposition}
`{size}
`
`The current (that is, the next available) output position on the screen is
`indicated by a cursor symbol — frequently a flashing block or underline
`character. The commonest way of causing a message to be output in a
`particular slot is to
`
`' move the current position to the starting (row,col) of the slot;
`0 use the ‘teletype’ functions provided by the programming language to
`output the content, suitably justified, at the new position.
`
`Some programming languages, such as the various BASIC dialects,
`provide facilities within the language itselffor repositioning; others, including
`PASCAL, do not. However, most microcomputers, dumb VDTs and printers
`will reposition the cursor in response to the output of a specific string of
`characters.
`
`The sequence may be a single ASCII character. Most devices will respond
`to the statement
`
`write (chr(l2))
`
`by ‘form feeding’, i.e. skipping to a new page on a printer, or clearing the
`screen and positioning the cursor in the top left corner on a screen. Linefeed
`(ASCII character 10) and Carriage Return (ASCII character 13) are other
`examples of such special characters. Normally, a sequence of characters is
`needed to control positioning; since the first character is usually Esmpe
`(ASCII character 27), they are commonly called Escape sequences.
`The precise sequence for a particular operation varies with the device. A
`
`

`
`Input/output processes
`
`41
`
`standard has been produced - the ANSI terminal specification — to which
`many devices conform.
`It defines sequences for particular operations,
`including cursor positioning and clearing areas of the screen; a subset is
`illustrated in Fig. 3.4. (<ESC> is the ASCII character Escape and the
`notation <j> means that <j> should be replaced by the relevant value
`expressed as a character sequence. For example, <ESC> followed by the
`characters [ISA will move the cursor up 15 lines.)
`
`move cursor up n lines
`<ESC> [<n> A
`move cursor down n lines
`<ESC> [ <n> B
`move cursor right n columns
`<ESC> [ <n> C
`move cursor left n columns
`<ESC> [ <n> D
`<ESC> [ <m> ; <n> H move cursor to column n of line In
`<ESC> [ 1 K
`erase from current position to end of line
`<ESC> [ 2 K
`erase all of current line
`
`Fig. 3.4. Typical ANSI terminal Escape sequences.
`
`Thus cursor positioning on a device which conforms to the ANSI standard
`can be accomplished by a procedure of the form:
`
`procedure CursorTo(row,co1:byte);
`begin
`write(chr(27),'[',row:1,';',co1:1,'H');
`end:
`
`There is nothing magical about the Escape character. The operating system
`contains procedures which effect the repositioning and which are invoked in
`response to these strings. These procedures may also be invoked directly from
`the application software by suitable low level system calls. Most operating
`systems will provide the facilities of Fig. 3.5.
`
`procedure CursorTq(row,col:byte)
`positions cursor to (row,col)
`procedure CursorAt(var row,col:byte)
`returns the current cursor position (row,col)
`procedure SwitchCursor(switch:OffOn)
`causes the cursor symbol to be hidden/displayed
`function
`TestCursor:OffOn
`
`test whether the cursor symbol hidden/displayed
`Fig. 3.5. Cursor control procedures.
`
`

`
`Chapter 3
`
`3.2.3 Output of Text with Particular Format Attributes
`
`Most VDTs provide more display facilities than just the ability to output at
`any point on the screen. In particular,
`they often provide a range of
`highlighting features which can be used to enhance the text of a message.
`Common highlighting features include:
`
`Colour. The text characters (or foreground) can be displayed in a different
`colour from the background. On some monochrome screens, a similar effect
`is produced with different shades of the screen’s base colour. Inverse video is
`a special case of this feature where the background and foreground colours or
`shades are swapped.
`
`Blinking. An area of the screen may be made to flash by displaying it
`alternately in normal and in inverse video. This is commonly used to highlight
`the cursor position.
`Bold Intensity. The ability to support different contrast levels and make an
`area of foreground appear brighter than surrounding areas.
`
`Highlighting facilities vary from device to device. Some provide only
`inverse video; others provide a wide range of colour tones and intensity levels.
`Several provide a number of different fonts (type size and face) for the text
`characters. In fact, the same device may provide a different range of features
`depending on the mode to which it has been initialised; for example, an IBM-
`PC may be set to display 40 or 80 columns, colour or monochrome and in
`various resolutions. In Chapter 6, we discuss guidelines on where and when
`highlighting features should be used. For the present, we will concentrate on
`how they are implemented.
`In the general case, we may represent the video attributes associated with
`an output text message by a data structure of type
`AttributesType = record
`foreground : colours;
`background : colours;
`blink
`: OffOn;
`bold
`: OffOn;
`font
`: TextStyles;
`end;
`
`where
`
`colours
`Off0n
`TextStyles
`
`. .
`
`= (black, blue, green .
`= (off,on);
`= (roman, .
`
`.
`
`. . .);
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .
`
`.
`
`. );
`
`

`
`Input/output processes
`
`43
`
`Highlighting facilities may often be invoked by means of escape sequences
`similar to those for positioning. The range of facilities, and the sequences
`which invoke them, should be included in the documentation for your
`particular device. For example, an IBM-PC Escape sequence may be used to
`switch inverse video on or off with a procedure of the form:
`
`procedure inverse (switch: Offon) ;
`begin
`if switch=on then write(chr(27),'[7m')
`else wr1te(chr(27),'[Om');
`end:
`
`Once a feature has been ‘switched on, it remains on until it is ‘switched off’.
`Thus, to output a particular message in inverse at row 10, column 16 requires
`a sequence of statements of the form:
`
`CursorTo(10,16);
`inverse(on):
`write('this message in inverse at (1o,l6)'):
`inverse(off);
`
`How does the device know what highlighting features are in force when a
`particular character is to be displayed? In most microcomputers the screen is
`memory—mappea'. For each position on the screen there is a corresponding
`area of memory which specifies what is to be displayed at that position and
`in what format; we will refer to this area as the video map. In a character-
`mapped display, the smallest addressable position on the screen is a complete
`character. On an IBM-PC, highlighting features are accommodated by
`reserving two bytes for each character position on the screen — the first,
`called the attribute byte, specifies how it is to be displayed and the second,
`called the content byte, specifies the character itself — as in Figure 3.6.
`
`char m+l
`
`char m
`attr m+l
`attr m
`blink (1 =on,0=off)
`i-~bit7
`bits 6 5 4 background colour (choice of 8 shades)
`bit3
`bold (1 =on,0=ofl)
`bits 2 I 0 foreground colour (choice of 8 shades)
`Fig. 3.6. Character video map.
`
`

`
`44
`
`Chapter 3
`
`There are 3 bits for both background and foreground colour to correspond to
`the 3 phosphors (red, green, blue) from which the colours are produced.
`‘Black’ is generated with all 3 bits set to off and ‘white’ with all 3 bits set to on.
`
`In the example of Figure 3.6, a memory area of 2 X 80 X 25 bytes
`(approximately 4K) is required for the video map of a standard 80 column by
`25 line display. The organisation of the memory map may not correspond
`directly with the layout of the screen in the way that Fig. 3.6 suggests. Column
`1 of row n+1 may not immediately follow column 80 of row n in the map.
`With a smaller video map, less features can be accommodated; with a much
`larger map, the system may maintain copies of several physical screens
`simultaneously or provide a large ‘virtual’ screen only part of which appears
`on the physical screen at any one time. We shall see in Chapter 10 that this
`feature of modern microcomputers can be used to provide an interface
`technique called windowing.
`The interpretation of the Escape sequences which set attribute values is
`supported by routines in a microcomputer’s operating systems which write
`directly into the video map (and hence to the screen). Often system calls are
`provided which can be invoked directly from the application software; these
`may provide the programmer with access to more highlighting features than
`are available with the Escape sequences. For example,
`
`PutChar(content,attributezbyte)
`
`might be an assembler routine which causes the operating system to write the
`character specified by content into the video map at the current cursor
`position, set the attribute bits to correspond with the value specified by
`attributes, and finally advance to the next position. Most operating systems
`will support an equivalent to PutChar and a corresponding procedure,
`GetChar, which returns the content of the current position on the device, and
`the value of its attributes.
`
`Defining the attributes in terms of actual bit patterns in the video map is
`both unwieldy and inflexible; it is preferable to specify them in terms of the
`attribute data structure which we defined earlier. The low level routines can
`
`be incorporated into procedures which convert the enumerated types of this
`data structure into the relevant bit patterns for a particular device. Suitable
`procedures would take the form
`
`procedure WriteVideoMap(eh:char;attributes:AttributesType)
`procedure ReadVideoMap(var ch:char;var attributes:AttributesType)
`
`

`
`Input/output processes
`
`45
`
`A string can be displayed with particular attributes by repeated calls to
`WriteVideoMap, as illustrated by the Displaystring procedure of Fig. 3.7.
`
`procedure Displaystring(content:str1ng7
`attributes:Attr1butesType);
`var size,k : byte;
`begin
`size:-1ength(contcnt);
`for k:- 1 to size do WtitevidaoMap(content[k],attributes)7
`and:
`
`Fig. 3.7. Displaying a message with given attributes.
`
`3.2.4 A Generalised Output Process for Text Messages
`
`We are now in a position to generalise the output of a text message to a
`device such as a screen. An output message is represented by a variable,field
`(oftype FieldType), whose structure is defined by the type declarations of Fig.
`3.8.
`
`byte
`colours
`Offon
`Lettcentrekight
`S1otType
`
`Attributesrype
`
`o..255:
`(b1ack,b1ua,green,cyan,red,magenta,ye11ow,white)7
`(off,on);
`(1eft,centre,right):
`record
`row
`col
`width
`end;
`
`byte:
`- byte:
`byte:
`
`record
`. colours:
`foreground
`' colours;
`background
`. orconz
`blink
`Orton:
`bold
`justification : Lettcentrenight;
`end:
`
`Fic1dTypo
`
`record
`content
`slot
`attributes
`end:
`Fig. 3.8. Type declarations for the output message process.
`
`. string;
`' s1otType;
`AttributesType;
`
`For simplicity, we restrict our discussion in this chapter and the following
`chapters to the display of a field, i.e. a message which starts at a specified
`(row,col) character position and extends for a specified number of character
`positions. In other words, we have omitted ‘height’ from the SlotType
`declaration.
`
`

`
`45
`
`Chapter 3
`
`Also, for simplicity and because it is a feature which is not available on a
`number of devices, we have omitted text fonts. It is not difficult to incorporate
`this facility, although different font sizes may make it tricky to operate in fixed
`integral character positions.
`We have introduced a new attribute — justzfication. The reason for this
`attribute is merely to make the display offield. content more convenient. The
`number of ‘significant’ characters in the content string may be less than
`fieId.s1ot. width; for example, we may wish to display a short string of black
`text characters centred within a longer band of blue background. We could
`assign a string, suitably padded with leading and trailing spaces, to content.
`Introducing a justification attribute merely saves the designer the trouble of
`calculating the number of padding spaces required. The string will be
`displayed automatically with the appropriate number of padding spaces.
`We require a mechanism for assigning values to an output field. This is
`done by the CreateFie1d procedure, which takes the form:
`
`procedure CreateField (var field:FieldType;
`message:string;
`row,col,width:byte;
`AttributeString:string);extemal;
`
`The field represented by Fig. 3.9 can be initialised by the statement:
`
`CreateField (Figure 3.9, ‘My Message Displayed Here’,6,l0,3l,
`‘fore=b1ack,back=blue,just=centre’);
`
`My Message Displayed Her:
`
`Let us examine CreateField more closely. Assigning values to content and
`slot raises no queries but the assignment of attributes deserves some attention.
`We have already seen that it is desirable to specify the attributes at a
`conceptual level rather than in terms of how they are implemented. It is
`tedious to specify a value for each attribute every time we define a field; we will
`
`

`
`Input/output processes
`
`47
`
`frequently want the same set of values. More significantly, we will ‘bake’ this
`set of attributes into our application software since, if we add a new attribute,
`we will have to amend all existing software to include the additional value.
`Therefore we specify the desired attributes as a string of characters. This
`string consists of a series of settings separated by commas, and with each
`setting having the form
`
`keyword = value
`
`where keyword identifies a particular attribute (fore, back, blink or bold) and
`value the enumerated type value which the attribute is to take. Any attributes
`which are not specified explicitly take a default value. In our example, the
`blink and bold attributes take their default values of ‘off’ because they are not
`
`specified explicitly. The default values for background and foreground are
`‘black’ and ‘white’ respectively, and the default value for justification is ‘left’.
`In order to manipulate the field data structures we assume a library of
`procedures of the form detailed in Fig. 3.10. These procedures utilise the low
`level routines for positioning and attribute setting described in the preceding
`sections. Appendix G contains a library of suitable PASCAL procedures.
`Note that these procedures are not restricted to any particular screen device
`—— device dependence is localised within the low level routines.
`The field in Fig. 3.9 can be output to the screen by a statement of the form
`
`DisplayField(Fi,<,mre3_9);
`
`The content of the field in Fig. 3.9 can be ‘cleared’ by a statement of the form
`
`ClearField(Figure3_9);
`
`procedure change!-‘:Le1dcon,tent (var field: FieldType ;
`NewContent:string)iexternal;
`procedure changeFie1ds1ot(var £ie1d:Fie1dType:
`row,co1,width:byte):externa1:
`procedure ChangeFie1dAttributes(var £ie1d:F1e1dType:
`NewAttrihutes:string)rexternali
`procedure c1earF1e1d(£ie1d:Fieldrype);externa1;
`procedure createFie1d(var t1a1d:F1e1dType;
`message:strinq;
`row,co1,width:byte:
`Attributestring:string);axterna1;
`procedure Disp1ayFie1d(fie1d:Fie1d'l‘ype) :ext:erna1;
`‘procedure Hiderield (field: 1'-‘1e1d'rype) ;externa1:
`
`Fig. 3.10. Field manipulation procedures.
`
`

`
`48
`
`Chapter 3
`
`This temporarily sets the foreground to the same colour as the background of
`the field and redisplays it. If the background colour of the field is different
`from that of the rest of the screen, the area occupied by the field will still be
`visible but the content will be invisible. This can be used to indicate the
`
`location of a messag but without displaying the message content.
`There are occasiéreis when the dialogue process wishes to draw a user’s
`attention to a message which has already been displayed i.e. to repeat the
`message with greater emphasis. Rather than creating a new message, this can
`be done by changing the specification of an existing message and redisplaying
`it. For example, the statements
`
`ChangeFieldAttributes(Figure3_9,‘fore5white’);
`DisplayField(Figure3_9);
`
`will redisplay the field in the same position but with white text on a blue
`background. There are corresponding procedures to change the content or
`the slot.
`
`Finally, we may wish to hide the area of the screen occupied by the display
`of a field. This is accomplished by a statement of the form:
`
`HideField(Figure3_9);
`
`Figure 3.11 illustrates the use of these procedures to display the range of
`shades available on an IBM-PC colour screen. The program ShowColours
`outputs a pyramid with shades lightening from black at the top to white at the
`bottom; each row of the pyramid contains the shade caption in the same
`colour as the background but in bold intensity.
`
`3.3 Input of a Text Message
`
`3.3.1 Standard Input from the Keyboard
`
`The keyboard is the archetypal input mechanism of interactive computing. It
`can be used for the entry of any text-based input and is appropriate for low
`to moderate volumes, depending on the proficiency of the user. Where large
`volumes of input from fairly standard source documents are involved, an
`automatic data capture device such as an optical character reader should be
`considered; these devices are widely used by public utilities for processing
`customer account payments and by banks for processing cheques.
`
`

`
`Input/output processes
`
`program Showcoloursi
`type
`(include field Type definitions of Figure 3.8)
`var
`: Fie1dType;
`outfield
`rov,col,width : byte;
`k
`: byte;
`shade
`: array[1..8] of string:
`
`shade[3]:-'green':
`shade[6]:-‘magenta’;
`
`(include tield Procedure declarations 01 Figure 3.10)
`procedure c1earscreen:externa1:
`begin
`shade[l]:-‘black’ ; shade[2]:-'hlue'
`shade[4]:-'cyan'
`; snade[5]:-'red'
`shade[7]:-'ye1loH'; ahade[8]:-'vhite',
`Clearscrnenl
`Create1ield(OutPield,‘Colours Availab1e',2,l,BO,
`'back-white,fore-b1ack,just-centre‘);
`Dieplayr1eld(0utPield)r
`row:-3; col:-351 width:-10;
`for k:-1 to 8 do
`begin
`changeFie1dContent(outfield,shade[k])i
`change!ie1dAttributee(outfield,
`concat('bo1d-on,back-',shade[k],‘fore-',shade[k]))7
`row:-row+11 col:-col-2; width:-width+4:
`changerieldslot(outrield,rou,co1,width):
`Disp1ayrie1d(oucF1e1d):
`end;
`end.
`(showcolouri)
`
`Fig. 3.1]. A colour pyramid.
`
`Other equipment which can be used to substitute or supplement keying
`includes badge readers (into which you insert your bank service card at the
`automatic till) and barcode scanners (used to identify products at retail
`checkout desks). In both cases, their use eliminates the need for the user to
`enter a long and meaningless string of digits to identify the customer or
`product code.
`
`EEQIQIEE
`
`Fig. 3.12. Olivetti M24 keyboard.
`
`

`
`50
`
`Chapter 3
`
`In certain systems a full keyboard is unnecessary or undesirable and a
`customised keyboard may be used, e.g. the numeric keyblock on an automatic
`bank till. However, unless they are to be produced in large numbers,
`customised keyboards are expensive. Many improvements on the traditional
`QWERTY layout, illustrated in Fig. 3.12, have been proposed and shown to
`reduce the physical strain on the user;
`thus far it has withstood all
`competitors.
`The basic mechanism by which input is received by a program is the same
`for all keyboards. Most high level languages provide a procedure to read
`input delimited by an end of line marker such as Carriage Return. Thus in
`PASCAL, the statement
`
`read (x)
`
`reads a value from the keyboard and assigns it to variable x.
`
`The use of a standard input facility, like READ, has a number of implications
`for the interface. The processing which occurs to effect the input is as follows:
`
`repeat
`— wait for input to become available;
`— interpret any control sequences for editing (such as Backspace or
`Delete) or screen positioning;
`— echo the edited/interpreted input to an attached screen;
`
`until end of input is indicated by the user pressing the Carriage Return key.
`
`In a language such as PASCAL, the input will then be checked for type
`consistency with the input Variable and converted as appropriate, or will cause
`an error.
`
`For many text-based applications, the processing described above may be
`exactly what is required. However, it does have limitations. The application
`may not want the dialogue to wait for input, but rather to examine the
`keyboard to see whether or not a key has been pressed. This is necessary
`where the system repeatedly carries out a process until the user presses a key
`to terminate it. A common example occurs when a source file is listed on the
`screen. Lines from the file scroll up the screen until the user causes a pause,
`typically by pressing control—S.
`It may be undesirable to echo what the user types onto the screen.
`Obviously password protection would be of little use if the password were to
`be displayed whenever it was entered.
`The application may interpret editing keys in a non-standard manner.
`
`

`
`Input/output processes
`
`51
`
`the Backspace key is
`During execution of a PASCAL read instruction,
`interpreted as a destructive backspace, i.e. the previous character is overwrit-
`ten. With a form displayed on the screen, the dialogue may want to interpret
`the Backspace key as ‘position the cursor at the preceding field’.
`If the dialogue is expecting a single character reply, the user should not be
`required to press the return key; the input should terminate when one
`character has been entered.
`
`3.3.2 Character—by-Character Input
`
`To support these variations, many languages allow character-by-character
`input. Even if the language (as with PASCAL) does not include it, many
`operating systems provide the facility via a low level routine which can be
`linked with the language’s procedures. The essentials of such input are that:
`The application software can interrogate the keyboard to see if a key has
`been pressed. If it has, the character code corresponding to the key will be
`returned; otherwise an indicator such as ASCII NUL (ascii 0) will be
`returned.
`
`The majority of input codes will not be interpreted to see if they represent
`control sequences (it may not be possible to trap some Resets). In
`particular, a Backspace will appear as the ASCII character BS (ascii 8).
`The input will not be echoed automatically onto the screen.
`
`This facility gives the designer the ability to control the way in which input
`is received from the keyboard. A program can wait for input by repeatedly
`scanning the keyboard until a non-null character is obtained. Input can be
`echoed by displaying characters as they are received; in fact, numeric input
`can be echoed right-justified, and alphabetic input can be echoed left-justified.
`Since control sequences are not interpreted by the operating system, the
`dialogue process can interpret any character, or sequence of characters, in any
`way. The corollary of this freedom is that it must undertake any editing
`functions required.
`A final point to note is that this mechanism only supports input of type
`Char. Although this may seem a disadvantage, a little thought should suggest
`that all text input (including that of numbers) should be as characters which
`are then converted explicitly by the application software. No system should
`crash because a keying error caused a type mismatch in a PASCAL program!
`Handling character—by—character input requires the existence of an external
`procedure of the form
`
`

`
`52
`
`Chapter 3
`
`function GetKeyChar(WaitSwitclI:WaitType;EchoSwitch:EchoType):byte;
`
`where WaitType = (Wait,NoWait) and EchoType = (Echo,NoEcho) and the
`byte value returned contains the ASCII code of the character corresponding
`to the key.
`
`3.3.3 Handling ‘Special’ Keys
`
`Most keyboards contain a number of ‘special’ keys in addition to the
`alphabetics and the numeric digits. These ‘special’ keys include editing keys
`such as Backspace, cursor control keys and function keys. If GetKeyChar
`returns the corresponding ASCII code when an alphabetic or numeric is
`pressed, what does it return if a special key such as the cursor for function
`key F l is pressed?
`
`Keys such as Backspace and CarriageReturn also return a single ASCII
`code. On some devices, all the keys operate in this manner; that is you can test
`for function key Fl by a statement of the form
`
`if key = n for some 0 < n < 256
`
`Unfortunately, not all devices are so helpful. Many terminals and microcom-
`puters (such as the IBM-PC) return a sequence of several characters for the
`depression of a single function or cursor control key. Often this sequence
`starts with the ASCII NUL character which is also used to indicate that no
`key has been pressed; a function like GetKeyChar will not handle special keys
`on these devices.
`
`There is a solution to this problem. Each key on the keyboard (even
`ShiftLock) has a unique numeric code, a scan code associated with it. The scan
`codes for the keyboard illustrated in Fig. 3.12 are shown in Fig. 3.13. When
`a key is depressed, the corresponding scan code is generated. Some keys
`(Shift, Control, CapsLock, etc.) do not produce an input ‘character’. They
`
`Fig. 3.13. Olivetti M24 scan codes.
`
`

`
`Input/output processes
`
`53
`
`have no meaning except when combined with a ‘character’ key and merely set
`a KeyBoard State flag. If the ‘c’ key is depressed, the keyboard handler
`translates it as ‘C’ or ‘c’ or ‘control-C’ and generates the corresponding ASCII
`code by interpreting the scan code in light of the Keyboard State flags. A
`sequence ofASCII codes for a function key or cursor control key is generated
`in a similar manner.
`
`Many operating systems provide entry points which enable low level
`routines to access the scan codes rather than just the translated ASCII codes.
`Consider an external procedure of the form
`
`procedure GetKeyScan(WaitSwitch:WaitType;EchoSwitch:EchoType;
`var scan,ascii:byte); external;
`
`This operates in a similar way to GetKeyChar except that it returns values for
`both the scan code and an ASCII interpretation of this code. The scan code
`will be non—zero if and only if a key has been pressed. For a normal key, the
`scan code will be interpretable as an ASCII value which will be returned in the
`variable ASCII; for special keys, no such interpretation will be possible and
`so the value of ASCII will be zero.
`
`By associating with a singl