Rick Knoblaugh is a Systems Engineer specializing in systems programming for PCs. He is the coauthor of Screen Machine, a screen design/prototyping/code generation utility. He may be reached at 15014 River Park Dr., Houston TX 77070.
Prototypes and code generators can significantly reduce development costs. In this article I'll discuss a recent consulting project and show how the "Screen Machine" — a prototyping tool which I am making available to other programmers as shareware — assisted in prototyping, generating C code for the user interface, and documenting the system.
The Application
My project was a student grade tracking application for a high school. The software allows student names and grades to be scanned into a PC clone using an optical mark reader, a scanning device which reads forms which have been marked with a pencil. Student names and grades can also be manually entered or edited.The product enables teachers to maintain their grade books on a PC. Grade tracking and printing tasks, such as letters to parents, are all handled in a menu-driven environment. Thus, the application required menus, data entry screens and help screens.
I began by planning the major components of the software, such as the scanner communications and the decoding of the scanned data. Next I needed to develop a user interface from which all program functions could be selected. For this phase the user interface prototyping software was invaluable.
Benefits Of Prototyping
In the past programmers who have developed interactive programs, have painstakingly designed the appearance of screen displays on paper and then written the code for these user screens.Today, many developers are using some type of screen prototyping software. Most prototyping tools permit screen design using a powerful screen editor. Screen editors make it much easier to manipulate blocks of data, to center screen data, and to experiment with color and other aspects of screen appearance.
In addition to a screen editor, prototyping packages usually include some control facility that allows branches to various screens to depend on user input. This allows the developer to create the "look and feel" of a user interface before any code is written. Prototyping also lets the user become more involved in the design of the user interface. More importantly, it allows the programmer to be more creative and to develop an interface that makes sense.
Some prototyping tools also provide code generation for the screen displays. Once the screen design is finalized, the program automatically generates the associated source code.
Screen Machine
Screen Machine runs under MS-DOS and consists of a screen editor/code generator, a mini-language for prototyping the flow of application screens, and a TSR screen capture program which allows any text mode screen to be imported into the screen editor.Screen Machine can generate source code for screens in your choice of C, BASIC, Turbo Pascal, 8086 assembler, and dbase. Screen Machine is limited to handling display portions of screens only; it does not handle data input. The prototyping module permits the input of single keystrokes, allowing screens to be displayed when the operator selects a menu option or presses a specific key.
Designing Screens With SCREEN
I experimented with the appearance of the grade tracking application screens using Screen Machine's screen editor and code generator, SCREEN.EXE. As with most applications, I started with the main menu (Figure 1) .The SCREEN box drawing feature makes it easy to put borders around menus and other screens. Text can be centered on a given line of the screen or within the graphics character borders of a drawn box. You can even shift the entire screen left or right to aid in centering screen data and attributes. Other screen editor features include: inserting and deleting lines, copying and moving blocks, selection of color, reverse video, undo of last editing function, key stroke macros, and online help.
I saved my designed application screens in Screen Machine screen data files. (Screens can be saved with or without attributes). If no color or reverse video is needed, the screens can be saved as ASCII text files.
Prototyping The Interface
Once the data files for all application screens are complete, the programmer develops an executable simulation of the application interface using the Screen Machine's mini-prototyping language module, SHOW.COM. The completed simulation will display the main menu, accept keystrokes, and based on these keystrokes, select other application screens for similar processing.The SHOW mini-language consists of display/keystroke input statements, case statements, and goto and gosub statements. The heart of these is the display/keystroke input statement, whose syntax is:
Filespec [basekey max] [/Tn] [/An] [/Xn]Filespec names the screen data file to be displayed. (e.g. I saved my main menu screen data file in C:\GRADE\MAINMENU.SRN.) The basekey is optional and represents the lowest-valued key accepted as input from the user when the screen is displayed. The basekey is one of these:
The max cannot be specified unless basekey is specified; it is the highest-valued key accepted as input. If input from a given screen falls neatly within a range of keystrokes (e.g. if on my main menu only "1" to "9" were used, and not <Alt><H>), specifying basekey and max eliminates all unwanted keystrokes.
- A specific key, enclosed in quotation marks (e.g. "1").
- A decimal scan code value (unquoted) (e.g. 59 for the <F1> key).
- An unquoted asterisk (*), which is taken to mean "any key".
The T switch specifies a time value in seconds — useful for creating timed "slide shows". SHOW will display the screen data file and then wait n seconds (0-255) before displaying the next screen.
The A switch displays a screen data file in a certain attribute. This is generally only used if you have not saved attributes in your screen data files.
The X switch is the key on which a "getout" is performed. "n" is specified in the same manner as basekey and max, i.e. either a quoted character or an unquoted scan code. A "getout" is accepted as a valid key press and performs any pending return or else returns to the operating system.
Case statements allow branches to other portions of a SHOW command file to depend upon keystrokes input via the display/keystroke input statement. The syntax for the case statement is:
case [key] [range] [S: G: R:] [label name]If a keystroke matches key or falls within range, control is transferred to label name. If S: is present, the transfer is executed as a gosub, meaning the address of the next display/keystroke input statement is put onto the "stack" and control is transferred to the label. G: does a goto transfer to the label. R: returns to the label (similar to BASIC).The syntax for labels is the same as in MS-DOS batch files (i.e. a ":" followed by a label name).
The grade tracking SHOW command file appears in Listing 1. The top of the command file displays the main menu which is stored in the Screen Machine screen data file, MAINMENU.SRN. The asterisk after the file name instructs the SHOW program to wait after displaying the main menu until some key is pressed. The /X indicates that if a 9 is pressed, the SHOW command file should terminate and return to MS-DOS. The case statements perform gosubs to other labels in the command file. For example, if the user presses a 6, SHOW will gosub to the label otherprint where the print options menu is displayed and processed.
The strange looking NUL screen data file name followed by the case * G:top is necessary because the limited SHOW command set only allows unconditional branching to be initiated in case statements. Case statements can only be performed after a screen data file has been displayed by a display/keystroke input statement. The reserved screen data file NUL only satisfies the case statement by simulating a screen display and a key stroke entry.
The asterisk indicates that if any key is pressed, a goto should be performed to the label top. After the appropriate gosub is processed from the main menu, control transfers back to the top of the command file.
Generating The Source Code
A SCREEN program configuration option allows you to select the language to be generated.When SCREEN generates C code, it declares a structure _scrn and defines a global array of structures of type _scrn (Listing 2) . Notice that the array of structures is named with screen_ followed by the name of the screen data file to prevent naming conflicts.
After including these statements in your program, you can either write a routine to display the arrays of structures, or include the routine supplied with Screen Machine in your program as in Listing 3.
The routine uses the BIOS software interrupt 10h function 9 to display the arrays of structures. Function 9 writes a character and attribute at the current cursor position. The Microsoft C library function _settextposition is used to position the cursor.
The function disp_screen is called passing the name of the array of structures to be displayed and a flag indicating whether the screen should be cleared prior to displaying the data. disp_screen clears the screen using the background color defined in the variable color_back_grnd. This should be set to the desired background color.
Data Entry
Because Screen Machine handles only display portions of screens, I used my own general-purpose data entry routines for those portions of the application where data entry was required.
Screen Capture
A third Screen Machine module CAPTURE.COM is a TSR program that allows text mode screen displays to be captured and stored on disk. This utility makes it easy to include application screens, complete with sample data in the users manual.CAPTURE takes over the shift print screen function (interrupt 5). When the program is invoked and becomes resident, command line options specify the file name under which screen data files are to be stored and whether or not attributes should be included in the screen data files. If attributes are not desired, screen data is stored in ASCII text files.
Captured screens can also be used as input into the screen editor/code generator. This means that any text mode screen can be translated into source code which will display that screen in one or all five supported programming languages. This capability can be used when translating an application from one language to another or if you want to generate source code for screens created with a prototyping tool that doesn't support source code generation.
Conclusion
Screen Machine does several things satisfactorily. Its lack of support for input fields may preclude your using it for some applications. Certainly, if you need really detailed simulations of your programs such as sound effects and emulation of disk I/O, you should use a more full-featured commercial prototyping program. Also, if you require a graphics interface then Screen Machine will not help you.