WO1991000575A1 - Computer operations recorder and training system - Google Patents

Computer operations recorder and training system Download PDF

Info

Publication number
WO1991000575A1
WO1991000575A1 PCT/US1990/003878 US9003878W WO9100575A1 WO 1991000575 A1 WO1991000575 A1 WO 1991000575A1 US 9003878 W US9003878 W US 9003878W WO 9100575 A1 WO9100575 A1 WO 9100575A1
Authority
WO
WIPO (PCT)
Prior art keywords
screen
recording
recorder
file
branch
Prior art date
Application number
PCT/US1990/003878
Other languages
English (en)
French (fr)
Inventor
Paul E. Williams
Kevin G. Mccarthy
Gerard J. Cerchio
Robert A. Alves
Original Assignee
Tds Healthcare Systems Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tds Healthcare Systems Corporation filed Critical Tds Healthcare Systems Corporation
Publication of WO1991000575A1 publication Critical patent/WO1991000575A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B19/00—Teaching not covered by other main groups of this subclass
    • G09B19/0053—Computers, e.g. programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3414—Workload generation, e.g. scripts, playback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices

Definitions

  • the present invention relates to a computer system wherein one computer program, or a cluster of computer programs, is used to make a recording of another computer program in operation. More particularly, the present invention forms a computer-readable file of records of inputs to, and outputs from, the other computer program. The file may then be edited and manipulated to produce a computer-assisted educational exercise,
  • the WHITNEY patents disclose a software training system including a computer, a cassette tape player system, and software for running the computer.
  • This software includes the target program which the student is learning to use and courseware which defines a multiplicity of events which correspond to different portions of a predefined training lesson.
  • the tape player system is attached by an interface to one of the computer's input/output ports.
  • the interface allows the computer to turn the tape player on and off, and also transmits keystroke data from the left track of a stereo cassette tape player, to the computer. Oral instructions or other sounds recorded on the right track of the stereo cassette are played over a speaker.
  • the training system works by alternately turning on the tape to give the student oral instructions and to get keystroke data from the tape, and then turning off the tape player while the student enters keystrokes.
  • the keystrokes entered by the student are compared with a filter specified by the currently active event in the courseware. If a correct entry is made, the tape player is turned back on and the lesson continues. Certain predefined keystrokes from the tape player cause a new event from the courseware to be selected and for the tape player to be turned off. Furthermore, if the student fails to make the correct keystrokes within a preselected time period, the training system enters the correct answer for him and proceeds with the next portion of the training session.
  • the WHITNEY patents appear to use a co-resident program that records the user inputs, which are later fed back to the target program during the execution of the tutorial to obtain screen outputs. While this approach may be acceptable for limiting incorrect student input, it requires accessing the target program each time that a student is to be trained. Thus, the WHITNEY patents do not address the problem of expensive access time.
  • U.S. Patent No. 4,662,013 (“CERCHIO," one of the inventors herein) discloses an interactive training/expert computer system that includes a computer subsystem for executing computer programs. A keyboard is used for entering data into the system, and a CRT displays the results of executing a computer program in the computer subsystem. A preselected computer program is resident in the computer subsystem. A tutor module interrupts the flow of data from the keyboard, interpreting, and
  • manipulating, generating, and allowing functions are dynamically determined in accordance with predefined criteria dependent on the contextual circumstances in the running of the preselected computer program.
  • the CERCHIO invention involves an interactive software training system in which a co-resident "courseware module" serves as a tutorial co-program, the patent is not directed at how to make the courseware module, particularly a course module that functions without accessing the target program for each education exercise.
  • the present invention is designed to capture and/or create information and format it into a computer-based training exercise.
  • the recorder includes: a first digital computer; a memory device connected to the computer; and means for automatically recording in the memory the operations and the input of the first program.
  • the recorder may further include: a second digital computer connected to the first digital computer for hosting the first program and receiving the input via the first computer.
  • FIG. 1 is a block diagram of the present invention
  • FIG. 2 is a block diagram of the present invention that provides further detail of elements of FIG. 1.
  • FIG. 3 is a block diagram that provides further detail of recording emulator 8a of FIG. 1.
  • FIG. 4 is a block diagram that provides further detail of the record screen step 86 of FIG. 3.
  • FIG. 5 is a block diagram that provides further detail to the process key step 92 of FIG. 3.
  • FIG. 6 is a block diagram of the open file step 96 of FIG. 3.
  • FIG. 7 is a state diagram of the generic recorder 8b of FIG. 1.
  • FIG. 8 is a block diagram of the recorder data flow and memory organization of the generic recorder 8b of FIG. 1.
  • FIG. 9 is a block diagram of the resident portion of generic recorder 8b of FIG. 1 and interrupts.
  • FIG. 10 is a block diagram of the monitored interrupt 222 of FIG. 9.
  • FIG. 11 is a block diagram of the multiplex interrupt 224 of FIG. 9.
  • FIG. 12 is a block diagram of the clock interrupt 226 of FIG. 9.
  • FIG. 13 is a block diagram of the process keyboard 258 of FIG. 12.
  • FIG. 14 is a block diagram of the record key 280 of FIG. 13.
  • FIG. 15 is a block diagram of the C clock code 260 of FIG. 12.
  • FIG. 16 is a block diagram of the process flags 302 of FIG. 15.
  • IG. 17 is a block diagram of the screen differs
  • FIG. 19 is a block diagram of tmp in ignore region 382 of FIG. 17.
  • FIG. 20 is a block diagram of the record screen 334 of FIG. 15.
  • FIG. 21 is a block diagram of the keyboard interrupt 228 of FIG. 9.
  • FIG. 22 is a block diagram of the playback 22 of FIG. 2.
  • FIG. 23 is a block diagram of the process playback record step 522 of FIG. 22.
  • FIG. 24 is a block diagram of the automatic playback step 24 of FIG. 23.
  • FIG. 25 is a block diagram of the manual
  • FIG. 26 is a block diagram of the instructional playback step 28 of FIG. 23.
  • FIG. 27 is a block diagram of the proficiency playback step 30 of FIG. 23.
  • FIG. 28 is a block diagram of the print step 42 of FIG. 23.
  • FIG. 29 is a block diagram of the overall structure of modify 44 of FIG. 23.
  • FIG. 30 is a block diagram of the options menu mode 52 of FIG. 29.
  • FIG. 31 is a block diagram of the selection error mode 48 of FIG. 29.
  • FIG. 32 is a block diagram of the typing error mode 50 of FIG. 29.
  • FIG. 33 is a block diagram of the color/ASCII mode 54 of FIG. 29.
  • FIG. 34 is a block diagram of the LPW modify mode 58 of FIG. 29.
  • IG. 35 is a block diagram of the single screen utility 56 of FIG. 2.
  • FIG. 36 is a block diagram of the process option
  • FIG. 37 is a block diagram of the student diskette 32 of FIG. 2.
  • FIG. 38 is a block diagram of the course directory step 36 of the student directory shown in FIG. 37.
  • FIG. 39 is a block diagram of the search function 68 of FIG. 2.
  • FIG. 40 is a block diagram of the copy function 60 Of FIG. 2.
  • FIG. 41 is a block diagram of the delete function 62 of FIG. 2.
  • FIG. 42 is a block diagram of the rename function 64 of FIG. 2.
  • FIG. 43 is a block diagram of the append file function 66 of FIG. 2.
  • FIG. 1' is a block diagram of of the present invention.
  • FIG. 2' is a block diagram of Data Files 10a'.
  • FIG. 22' is a block diagram of Playback 22'.
  • FIG. 28' is a block diagram of Print 45.
  • FIG. 29' is a block diagram of modify 44.
  • FIG. 30A is a block diagram of Option Menu Mode
  • FIG. 35' is a block diagram of Screen Utility 56.
  • FIG. 44 is a block diagram of Screen Information.
  • FIG. 45 is a block diagram of Cursor Information.
  • FIG. 46 is a block diagram of Initialize
  • FIG. 47 is a block diagram of Initialize
  • FIG. 48 is a block diagram of Install KB
  • FIG. 49 is a block diagram of Monitor Keyboard Interrupt 2004.
  • FIG. 50 is a block diagram of Process Screen 2006.
  • FIG. 51 is a block diagram of Reset Interrupts 2008 .
  • FIG. 52 is a block diagram of Process Duplicate
  • FIG. 53 is a block diagram of Parse Key Table
  • FIG. 54 is a block diagram of Read Key Table
  • FIG. 56 is a block diagram of Process Key.
  • FIG. 57 is a block diagram of Screen Arrived
  • FIG. 58 is a block diagram of Process Displayable Key.
  • FIG. 59 is a block diagram of Process Function Key.
  • FIG. 60 is a block diagram of Autoexit Screen
  • FIG. 61 is a block diagram of Write to File
  • FIG. 62 is a block diagram of Process Temporary Write.
  • FIG. 63 is a block diagram of Process final
  • the present invention involves one or more computer programs in a digital system adapted to record the input to and output from a target computer program.
  • a digital system adapted to record the input to and output from a target computer program.
  • cbt.asm and other, smaller assembly modules include vidlib.asm, vidlib2.asm, int24.asm, model.asm,
  • the programs may be run on a personal computer, such as a PC or a PS2 (available from International
  • IBM Business Machines Corporation
  • the personal computer should have 64 OK memory, a keyboard, a monitor or CRT - - preferably adapted for color display, and, if desired, a pointer device such as a mouse or a light pen.
  • a pointer device such as a mouse or a light pen.
  • the term "input device” is used to encompass such input devices, as a keyboard, mouse, light pen, etc. that produce electrical signals representing, for example, keystrokes as input to the target program 4.
  • the personal computer may be used alone to operate both the program of this present
  • the personal computer operated by the present invention can be linked (by modem or cable and appropriate emulator software) to a host computer, such as an IBM 4300 series mainframe computer having the second program operating thereon.
  • a host computer such as an IBM 4300 series mainframe computer having the second program operating thereon.
  • a person experienced with the target program logs onto the personal computer.
  • the person then uses one of two alternative approaches to record the target program.
  • the first approach is via the use of a recording emulator which, by inserting calls to other routines of the present invention described hereinafter, a terminal emulator may be modified to allow it to record its use in a format that is useful for simulation/record-processing software called the "CBT."
  • CBT simulation/record-processing software
  • this invention also includes a second approach to recording the target program called the "generic
  • the generic recorder is a terminate-stay-resident ("TSR") program because, after it is loaded into the computer, it will stay resident and act unobtrusively in the background until it is called upon.
  • This recorder uses a Format Table File (“FTF”) that describes the recording characteristics of the program to be recorded.
  • FTF Format Table File
  • the FTF file also handles any specialized keyboard
  • the user loads the proper FTF file before starting to record. It is possible to have just one FTF file that is always loaded automatically with the recorder, or to create batch files that load the proper FTF file when beginning the target application program. Another FTF file may be loaded to record still another program without having to reload the generic recorder.
  • the user calls up the target program and can commence recording at any time or times.
  • the computer system does not record until a "start record hot key" has been pressed.
  • the user may optionally record just a single screen or start a process of automatically recording screens. If recording several screens, the system will record until the user hits the "end record hot key” to complete the recording and put the generic recorder into its unobtrusive background state again.
  • the user can continue with other transactions involving the target program, as described.
  • Each time that the start record hot key is hit the user is asked to enter a file name. Sequentially, by entering different file names, the user can continue to make several
  • the end result of the use of one of the above-mentioned means for recording is at least one recording in a file of a computer that can then become available to the CBT system for processing into a simulation and/or
  • the CBT is a computer program that is an application program in itself.
  • the CBT can use a recording (i.e., a data file) made with either the
  • the user may then call up the recording and edit it to produce a simulation in several formats.
  • One format adds educational information to guide a student through the simulation.
  • Another format involves essentially no instruction, but tests the correctness of the student interaction with the simulation.
  • FIG. 1 shows the general features of the present invention.
  • a personal computer 2 is running target computer program 4 that is the subject of a future
  • Program 4 may, for example, be an application program, like the customized software that operates a hospital, a word processing program, MS DOS, or an emulator. Indeed, program 4 may be essentially any program that is well-behaved in the DOS environment, i.e., any DOS program that does not improperly interfere with the interrupt processing of the computer 2.
  • Computer 2 can be connected to a host computer 6 by virtue of the contents of computer 2.
  • Computer 2 contains means for recording 8a and 8b, data files 10, and CBT 12.
  • Means for recording 8 includes recording emulator 8a and a generic recorder 8b.
  • Host 6 and computer 2 may be connected by means of the recording emulator 8a.
  • the line between the host 6 and target program 4 is hyphenated to indicate that the data file 10 may optionally be produced by the recording emulator 8a connected to host 6 and engaged in operations involving a target program 4 that resides at host 6.
  • Means for recording 8 link to CBT 12 via at least one data file 10.
  • Computer 2 also contains at least one FTF file 14b, which links the CBT 12 to the configuration program 18 for processing data received from the FTF 14b file.
  • Data file 10 may be comprised of a file of records of computer screens produced during the operation of program 4 and records of information input by the user. Although this data could be stored in separate files, or some other configuration, a file of records is preferred for efficiently keeping track of the sequence of the operations of program 4 with relatively more
  • the recording emulator 8a and CBT 12 could be integral as one program or a linked cluster of programs, as is suggested by a dotted line there between.
  • the controlling functions may be located in a terminal emulator that normally provides the link between the PC computer and mainframe environments.
  • "hooks" may be placed in the emulator 8a to allow control to be passed to the CBT 12 system.
  • emulator 8a would be the main program with a control loop that allows branching to CBT 12 code when characters are typed, pointer device selections are made, or CBT-set interrupt conditions are met.
  • a control loop code handles all of the pointer device and keyboard input activities in either this alternative configuration or in the configuration detailed herein. With the hooks, CBT 12 would get "first shot” at the input keys. Only when the PC computer 6 is actually connected to the mainframe would the emulator 8a/CBT 12 have its own keystrokes and control the operation. Such an emulator 8a/CBT 12 combination is available from TDS Healthcare Systems Corporation in
  • developer refers to a computer programmer who, for example, may be using the system to create FTF files or to otherwise have access to files or code segments that are not generally
  • the term "author” refers to the user that, for example, records the target program 4 and creates educational exercises.
  • a “student” refers to a user seeking to learn the target program 4, and has access to CBT 12 essentially limited thereto.
  • CTR.PEW Access to different parts of the system is controlled by a file called CTR.PEW.
  • the batch files that run CBTP will transfer the proper CTRx file into CTR.PEW.
  • These files have the following designations: developers have DEV; students have STU; and authors have a blank.
  • Authors can make a recording and do everything necessary to create and customize exercises. Authors also have the ability to delete files from the system, copy files, etc. Students can only run exercises. They get a student start-up screen, a registration screen, and then a course directory from which they can select the exercises. Alternatively, the present invention could be configured to allow students to hotkey to the mainframe and practice on it, after which they would be returned to the course directory.
  • Q-Screen One major example of screen reading is the concept of a QSCR ("Q-Screen"). Any screen that has those four letters in the first four screen positions (row 0, columns 0-3) is treated differently. The QSCR is followed by a space and is then followed by a single letter which describes various options for that screen. For example, a QSCR N is visible only to the author and never in a subsequently discussed playback mode, while a QSCR X identifies an exercise statement. These options are detailed later in this document.
  • Authors have access, via author menu 20, to playback 22 which has four modes: automatic playback 24, manual playback 26, instructional playback 28, and
  • Automatic playback 24 reproduces the recording of program 4 by automatically sequencing through the recorded screens with predetermined timing, which is adaptably changeable.
  • the second mode of playback 22 is the manual mode 26, which allows the user to review the recording by stepping through it one screen at a time.
  • Manual mode 26 allows spending as much time as needed at any particular point. This, for example, allows students to completely grasp a lesson presented on a screen of an exercise before moving to another screen.
  • Instructional playback 28 provides a step-by-step sequence of the QSCR instructional screens, along with the computer screens that simulate the program 4. It requires a correct answer to advance and provides hints and error messages.
  • the final mode of playback 22 is proficiency playback 30, which provides minimum educational guidance, but tests students on the correctness of their handling of the exercise with prompts and responses predetermined by the author(s).
  • Student access to the CBT 12 is much more limited than that of authors, but aspects of playback 22 may be made available to them. Students are provided with a diskette 32 which they may use separately from the rest of CBT 12. Students also get a special start-up screen, and, when a student has finished his/her studies, the CBT 12 will return the computer 2 to the start-up screen to wait for the next student to log on to do exercises.
  • the first step for the student is registration
  • the course directory 36 is a directory that includes a list of the different exercises available to students.
  • a course is a set of exercises.
  • students may alternatively choose to enter critique 38, normally the last task accomplished after completing the exercises.
  • Critique 38 allows students to provide feedback about their computer-assisted instruction and possibly other teaching as well.
  • Critique 38 presents a list of questions to, and receives responses from, the student. The answers may be accessed by authors for use in evaluating the course.
  • a management system interface 40 keeps track of information on the individual students and the different tutorials available to the individual users.
  • students may choose an exercise in a course.
  • a playback 22 mode selection must be made by the student from the alternatives available to the student.
  • the student selects one of the four previously discussed modes 24, 26, 28, or 30 available in playback 22.
  • the exercise in a data file 10 is accessed.
  • the next step is to update the directory 42. If the student has undertaken a test in proficiency playback 30, part of update
  • directory 42 involves calculating and storing student test score information. An exercise is flagged as completed when the highest mode available to the student for the particular exercise at issue has been completed. The modes go from automatic 24 to manual 26 to instructional 28 to proficiency 30. c) Help
  • Help system 44 can either be state driven or based on name or number parameters.
  • the help system is state-driven.
  • the user hits the "help" key, it calls a function that first determines where the user was in CBT 12 (e.g., in student
  • Playback 22 is linked to print 45, to facilitate producing hard copy of the data file 10. This is in addition to a subsequently discussed print page option. Playback 22 also is linked to modify 46 which faciliates changing the data file 10 to produce an exercise. Modify 44 is made up of a number of functions that allow the author to make certain kinds of changes. The author can make or change: a basic page 47 (e.g., a screen recorded to data file 10); a selection error 48 (i.e., a selection of a function key to change the basic page or screen, and an associated message to be displayed in response to a student input of the wrong function key); or a typing error 50 (i.e., text to change the typing expected on the basic page or screen and a message for typing the wrong text). Corresponding functions 42, 46, and 50,
  • options menu 52 may toggle to options menu 52 to choose from a number of different operations, including: insert, delete, save, replace, list, print page, and go forward. These operations allow manipulating the recorded data. Note that not all of these options are always available depending on what the user was doing before coming to the options menu 52, as is more fully discussed below.
  • Color/ASCII 54 is also accessable from functions 47, 48, and 50, and is essentially the screen-painting part of the CBT 12 system. Color/ASCII 54 allows the author to change the color at any character position on the screen (if it is a color screen) and type any graphic character. Note that these text-graphic characters are not all found on a keyboard. They could be entered from the keyboard through the use of the "alt" key being depressed while a number is entered. These options are more easily accessed via a chart displayed in color/ASCII 54. Color/ASCII 54 (and options menu 52) may also be entered from a single screen utility 56, as is more fully discussed below.
  • LPW 57 involves an "action key.”
  • An action key causes the screen to change and the exercise to advance to the next page. For example, when recording, the user may have hit an enter key to advance in the target program 4. Thus, the recording would show the screen change and that an enter key was the key that prompted it. Likewise, selecting an item at a row and column with a pointer device might trigger the screen change, and the device hit status, and row and column data are saved in the datafile 10 record.
  • the "LPW" or light pen window is simply a way to bring up the action key information on the screen to allow the user to change it.
  • modify 46 allow the author to take the recording of a sample run of target program 4, recorded via data file 10, and transform this record into an exercise.
  • Modify 46 allows the user to add in instructional comments and helpful hints on screens to allow the subsequent student(s) to learn the functioning of the target program 4.
  • Modify 46 also allows the author to change the function key(s) or text that produces a new screen in the record, as well as to create error messages. Further, modify 46 allows the author to rearrange and change the appearance of the screen to make an exercise more palatable and understandable to the student. e) Single Screen Utility
  • the single screen utility 56 is used to create help screens and other special screens. Unlike modify 46, the single screen utility 56 is not exercise driven, though it can be used to make or change screens which can later be incorporated into an exercise. In general, the single screen utility 56 allows creating screens from scratch or changing screens stored as part of data file 10. As previously mentioned, the utility 56 also allows access to color/ASCII 54 and options menu 52, and some options therein. Utility 56 is useful for updating control files, creating screen templates, creating single screens, and performing certain editing functions. f) Miscellaneous Functions
  • CBT 12 also has file functions 58 for manipulating the data files 10.
  • Copy 60 makes a copy of any existing file 10 in whatever disk drive directory the user specifies.
  • Delete 62 deletes any existing file 10.
  • Rename 64 renames any existing file 10, and append 66 takes two files 10, and joins them together to form one larger file. These functions process the data files as files and do not access the records individually.
  • Search 68 is logically separate from the file functions 58. Search 68 allows the user to search through one or more files 10 for the occurrence of an input string.
  • Defaults 70 allows the author to specify certain default conditions for the operation of the CBT 12 system, such as the printer identification, the automatic playback 24 wait time, and the disk drive where an exercise will be found.
  • FIG. 3 is a more detailed flow chart of the recording emulator 8a.
  • the recording emulator 8a is a standard terminal emulator. Recording emulator 8a is adapted with hooks in it to allow access to the remainder of CBT 12 if a flag is set for CBT 12 in the FTF
  • Recording emulator 8a uses control loop returns. In the control loop that switches back and forth from the CBT 12 program(s) and the recording emulator 8a main loop, there is a need to be able to direct what happens.
  • CBT 12 has "states” which tell what to do when events occur, such as when a key is hit and a function called CBT_Character_Trap is called. Further, there is a need to "interrupt" recording emulator 8a, to get it to send control back to CBT 12 under other conditions.
  • the p_Reset variable has six possible values. One of the six is reserved. The value three means that the user is a student and is used in the programs to display the proper screens (students get a different start-up screen, for example). The value five is set when a subsequently discussed critique page being sought was not found and returns back to the critique start. The value two is essentially a "press any key" type and will then return to the start-up screen values. If p_Reset is 11, it is in a timer situation signifying a waiting condition. When the wait condition is met (e.g.. when the user finishes an exercise playback 22), the value of this variable will become one.
  • P_Play_Int found mostly in CBT_Low_Interrupt, is really a playback state holder having normal values between 0 and 30 during the playback 22 routine.
  • the value four essentially is the normal value for "go off to playback 22 again," and this is also the value when the user selects an exercise mode just before it brings in the exercise.
  • the values of two, three, and five are found for timing waits or return locations after a visit to recording emulator 8a for an action.
  • P_Play_Int has a subset, p_Play_Int_Code which is set in the playback 22 functions to more specifically route the user to where he or she was. This is usually effective when p_Play_Int has come in with a normal value of four.
  • P_Int is used to take the value of P_Play_Int on entry into playback and holds that value for processing while in playback, zeroing out p_Play_Int so that it must be reset again while outside of playback to refine the effects of the action taken.
  • the recording emulator 8a begins with initialization step 72 which loads the FTF file 14b. If CBT 12 is to be supported, the user will set a flag to indicate that CBT 12 is intended (hence active). Thus, branch 74 tests whether the CBT 12 is active with respect to recording emulator 8a. If the CBT 12 is not active, the recording emulator 8a moves to exit point 76 to run as a normal emulator without CBT 12. Emulators, by design. are intended to connect to a host and this is part of their initialization 16 process. However, if the CBT 12 is active, the recording emulator 8a progresses to CBT 12 processing where a normal escape from the emulator 8a must always be examined first in CBT 12 to see if CBT 12 is finished.
  • CBT 12 determines when the recording emulator 8a will be able to quit.
  • the system is in the control loop where it is constantly evaluating the state, as is more fully discussed below.
  • the control loop is concerned with whether it is recording or not, whether any keys or pointer hits have been found, or whether any hot keys or escape keys have been pressed.
  • processing begins through this loop starting at the evaluation at branch 78 which would not be true on first entry but which is always the first test thereafter.
  • a yes at branch 78 leads to quit 80. Otherwise, the recording emulator 8a proceeds to branch 82 where it sees if a new screen message has arrived. If it has, the recording emulator 8a proceeds to branch 84 to test if a record flag is set.
  • the screen is recorded in step 86. If not, the screen is ignored.
  • the emulator 8a loops back to escape flag 78 from record screen 86.
  • the recording emulator 8a proceeds from branch 84 or branch 82 to a point where the recording emulator 8a tests whether a key was hit, at branch 88. If it was, the recording emulator 8a proceeds to process key step 92, and thereafter back to branch 78.
  • branch 90 if no key was hit, the recording emulator 8a proceeds to branch 94. If the user presses the hot key, a test at branch 94 will send the recording emulator 8a to open a data file 10 at step 96 and will start recording before looping back to escape flag set 78.
  • the recording emulator 8a proceeds to branch 98 to determine whether there is a pointer hit (i.e., was the mouse or light pen clicked). If there is a pointer hit, the recording emulator 8a proceeds to branch 100 where, if the record flag is on, the recording emulator 8a proceeds to test whether the hit and/or pointer location are valid at step 102. Thereafter, the recording emulator 8a loops back to the escape flag setting query at 78. If the answer coming out of branches 98 or 102 is no, then the recording emulator 8a proceeds to a CBT option 104, which allows exit from the recording emulator 8a. This option is to allow the CBT 12 to get control of program 4 if needed, for example, to keep the recording emulator 8b from interrupting any CBT 12 processes, such as storing a file or reading in multiple records.
  • FIG. 4 details the record screen step 86.
  • Step 86 begins with an inquiry at branch 106 to determine whether a typing buffer is open. If the typing buffer has previously been opened, before recording the next screen, it must be closed and written to a typing record in file 10, because the information in the buffer must belong to the previous screen. Otherwise, the recording emulator 8a proceeds to build a typing header in step 108. Because every screen record has a header record associated
  • the recording emulator 8a proceeds to write the typing record to the file at step 110.
  • the recording emulator 8a proceeds to write the typing record to the file at step 110.
  • recording emulator 8a proceeds to step 112 which closes the typing buffer and joins the no fork from the typing buffer open query of 106 at branch 114.
  • Branch 114 tests whether there is a function key in the typing buffer. If there is, the recording emulator 8a proceeds to build function key header bytes at step 116. If a function key was hit to trigger the screen record, the header will be constructed to store the identity of the key. Otherwise, the recording emulator 8a builds unsolicited header bytes at step 118, i.e., because where no key triggered the screen that came, the header must say so.
  • the recording emulator 8a proceeds from either step 116 or step 118 to step 120 to finish the header record. A function key or an unsolicited flag is only part of the header. Thus, the rest of the header is filled. Thereafter, the recording emulator 8a writes the file to memory at step 122 and exits at 124 back to the diagram set forth in FIG. 3.
  • the process key step 92 of FIG. 3 that evaluates the keyboard character input is detailed in FIG. 5.
  • Process key step 92 begins by checking whether an escape key was selected at branch 126. If the escape key was depressed, the recording emulator 8a proceeds to step 128 to set an escape flag. Thus, upon exiting at 130 to
  • the escape flag set test 78 will trigger quitting the recording emulator 8a.
  • the recording emulator 8a proceeds to branch 132 to check whether the key depressed was an end of record key. If it was, the recording emulator 8a proceeds to end recording step 134, which writes a "last record” flag and closes the file.
  • the recording emulator 8a proceeds to step 136, which sets record flag off (i.e., the hot key used to record is set to "off" so that the system will not record more data). The recording emulator 8a then proceeds to return 130. If the key being evaluated in branch 132 is not the end record key, the recording emulator 8a proceeds to branch 138 to check whether it is a function key. At this branch, if it is a function key, the recording emulator 8a determines whether the typing buffer is open at branch 140. If the typing buffer is open, then a typing header is constructed at step 142. The header is written to the data file 10 at step 144 and the typing buffer is closed at step 146 before return 130. If the typing buffer is not open at 140, the function key is stored in a buffer at step 144 before return 130. In FIG.
  • the recording emulator 8a proceeds to branch 150 and accepts the input key if it is a letter or number. In either case, the recording emulator 8a proceeds to branch 152 to check if the typing buffer is open. If the buffer is not open, step 154 opens the buffer. Once the typing buffer is open, step 154 places the letter or number key in the buffer at block 156 which then leads to return 130.
  • step 158 an unknown key test 158.
  • the recording emulator 8a ignores the key found and returns at block 130.
  • the computer is directed by the CBT 12 to first put a "D” in the buffer and then leave to await the next user input. Next time that the user types, i.e., the "0", the computer is directed to return to the buffer and amend the contents of the buffer to hold "DO".
  • the enter key triggers writing out the contents of the buffer as a typing record to the data file 10. Further, the enter key is the function key put in the header. The typing buffer is then closed to await the next typing.
  • FIG. 6 details the step open file 96 of FIG. 3.
  • the recording emulator 8a asks the user to input or find a file name at step 160.
  • the recording emulator 8a checks whether the file name already exists at branch 162. If it exists, then the recording emulator 8a asks whether the user wishes to overwrite the existing file at branch 164. If the user does not want to overwrite the file, then the recording emulator 8a asks the user for a new file name at branch 164 and loops back to step 160. If overwrite is desired at branch 164 or if the file did not exist at branch 162, the recording emulator 8a proceeds to open the file at step 166, and sets the record flag on at step 168 and proceeds to return 170. An escape (not shown) allows exiting if the user decides not to input a file name.
  • the generic recorder 8b in FIG. 1, is conceptually divided into two separately executable sub-parts.
  • the first sub-part i.e., program
  • This sub-part becomes resident at the time of execution and maintains a watch on the computer states by intercepting several of the hardware and software interrupts.
  • the hardware devices monitored are the system clock, keyboard, and pointer device.
  • an interrupt service routine has addresses or vectors that are numbered and correspond to fundamental routines that operate the computer.
  • the software interrupts monitored are: 1) ISR 5 Print Screen; 2) ISR 10 Video BIOS; 3) ISR 13 DASD BIOS; 4) ISR 23 Control break from the BIOS; 5) ISR 28 DOS idle interrupt; 6) ISR 21 DOS command request; 7) ISR 2F DOS multiplex interrupt; and 8) ISR 24 DOS critical error. All of these interrupts are monitored continuously except the last one, ISR 24. This interrupt is only intercepted during the recorder's disk read/write operations. At all other times this interrupt is set to the recorded task's critical interrupt handler.
  • the second sub-part of the general recorder 8b is the configuration manager 18. This sub-part is for interpreting the FTF file 14 and producing data structures within the resident recorder's memory space that control the operations of the generic recorder 8b. Such things as sampling algorithm selections for a sample rate, hold off times, start and stop sequences, and function key
  • sequences may all be defined within the FTF file 14 to later be translated by this sub-part for the generic recorder 8b, as is subsequently discussed.
  • This dual sub-part configuration allows the recorder to be reconfigured between programs for long, complex recording sessions. It also allows for custom tailoring of the generic recorder 8b even to the specific data being recorded.
  • the generic recorder 8b is developed for flexibility and configurability. These attributes allow recording the operations of a large number of target programs 4. The design is optimized to allow the
  • transition states are limited by control of: 1) a variable sample rate; 2) function key recognition; 3) function key hold off periods; 4) function key minimum and maximum settle times; 5) screen change hold off times; and 6) ignore regions.
  • Variable sample rate allows the recorder to adapt to each target program 4 by examining screen changes at a rate optimal to the performance of the target
  • the sample rate in this recorder program may be set to as many as 17 samples per second. This is the sample rate of an MS DOS clock in the personal computer 2. Given that there may be a faster source of interrupts on the host machine 2, the sampling interrupt routine may be coupled to the clock of host 6 to attain an even higher sampling rate. Another aspect of the sampling rate is that it may be modified by the recording algorithm.
  • the generic recorder 8b uses several forms of recording to perform its task. These algorithms modify the sample rate of the recorder, minimizing the
  • the input is first recognized by generic recorder 8b before the target program 4 receives the input.
  • the generic recorder 8b transmits the instructions to program 4 and then goes into a background mode for a sufficient amount of time to allow the target program 4 to finish processing the input.
  • the generic recorder 8b starts sampling the screen again.
  • the generic recorder 8b also waits for the screen to "settle" before it performs the recording of the screen resulting from the particular command. This maximum wait, or “settle time,” is again specified in the configuration file of data.
  • the settling of the screen is determined by sampling the screen in the same state twice in a row. Identical screens indicate that the target program 4 has finished processing the input and is now in an idle mode. The screen is then recorded to a data file 10.
  • the second form of adaptive recording used in generic recorder 8b is both function key hold off and unsolicited screen change record hold off. Function key hold off is similar to the above minimum/maximum sequence except that no maximum amount of time is specified.
  • the generic recorder 8b after a fixed amount of time, will sample the screen and record it to the data file 10.
  • the unsolicited screen hold off is for a different situation.
  • the second period of time is the time that it takes for the target program 4 to update the screen. This update may be taken into account by specifying a hold off rate in the FTF file 14.
  • the generic recorder 8b will turn off all sampling for a set period of time, allowing the target program 4 the maximum CPU time to complete its calculations and display.
  • the generic recorder 8b then will record the resulting screen to the data file 10.
  • the final recording algorithm is for screen ignores. Frequently, an application program will have a status area of the screen that is of little or no
  • This portion of the screen may be updated with every keystroke, such as a cursor position read out.
  • the data may be updated synchronously with the keyboard such as a display of a ticking clock.
  • the recorder would normally register these changes and then record screens per change that occurred. This would generate an untoward number of data screen records that may have to be edited out of the data file.
  • the generic recorder 8b is adapted to prevent this by allowing the FTF file 14 to specify a region of the screen that is to be ignored during screen comparing. Any changes within this rectangular region are not considered as a screen change and therefore do not trigger a screen record.
  • the generic recorder 8b allows for separate regions to be defined for both 40 to 80 column video modes.
  • the generic recorder 8b further allows for a trigger phrase on the screen when the ignore region algorithm should be invoked.
  • This trigger phrase is an ASCII string displayed on the screen whenever the user wishes the generic recorder 8b to ignore the region of the screen.
  • the phrase may be at any location on the screen.
  • the FTF file 14 specifies the row and column of the phrase along with the ASCII characters to seek.
  • the trigger phrase is first checked and then the ignore region is called if indeed the string does exist on the screen within the specified position.
  • the row and column may be set to zero by specifying an empty string ("") to indicate that no trigger must be sought before employing the ignore
  • the screen compare routine calls the ignore region compare routine whenever a difference is found in the specified video column mode.
  • the screen and type-in data for the generic recorder 8b are placed in a ring buffer which is fixed in size at the time that the generic recorder 8b program is compiled.
  • the begin ring pointer and end ring pointer respectively define the beginning and end of this buffer.
  • the write ring pointer defines the point which data goes into the ring. This data is placed into the ring buffer character-by-character, generated by the type-in record and screen record algorithms.
  • the "begin ring write” and "end ring write” pointers define the area of the ring last written to the file.
  • the begin ring write pointer is constantly monitored whenever data is added to the ring buffer. An overrun condition exists whenever the write ring pointer equals the begin ring write pointer.
  • the end ring write pointer defines the currently completed data structure within the ring buffer. This pointer is only moved when data structure has the final record trailer attached to it and is, therefore, ready to be written to the data file 10.
  • Screen records are completed at the time of recording.
  • the record-screen routine places the header in the ring buffer, compresses the screen data into the buffer and then appends the standard trailer at the end of the record.
  • the video mode state is then examined to discern whether or not the screen is in 80 column mode. If it is not in the 80 column mode, the screen record is finished, the end ring write pointer is set to reflect that it is finished, and the routine then returns to the caller. If it is in the 80 column mode, the above
  • the keyboard data type-in record is built up over an extended period of time with the program 4
  • a type-in buffer is therefore built through multiple entries into the keyboard section of the code. This requires that some state information be held about the status of the current type-in buffer.
  • the type-in flag tells if a type-in buffer is in progress.
  • the size 1 and size 2 pointer point to the size of the type-in buffer in the data ring buffer. These bytes are updated every time a key is recorded into the buffer.
  • the type-in record therefore "grows" as time passes to hold all of the typed characters in the user's input stream.
  • the end ring write pointer is not updated every time a character is recorded into the ring buffer because, for the CBT 12 to recognize the type-in record, a trailer must be appended to the end of the data. This trailer is appended whenever a screen record is triggered if indeed, there is a type in buffer in progress.
  • the ring buffer write routine is triggered by a fixed number of writes into the ring buffer.
  • the recorder compares the number of writes to the ring buffer to a constant that is defined when the program is compiled. If the number of writes to the ring exceeds this constant, then the write flag is set and the ring buffer is written to disk at the first DOS legal time.
  • This algorithm may be expanded to allow for a write, whenever the buffer reaches a certain percentage fill point that may be specified by the ASCII FTF file.
  • the generic recorder 8b produces formatted instruction files called "paths".
  • the generic recorder 8b requests the name of the file that the recordings are to be placed into at record initialization. This file is then examined to first see if it exists. If it does not exist in the current directory, then the generic recorder 8b creates the file and the recording session appears in the file as target program 4 operations progress. If the file already exists the generic recorder 8b must either append to the existing file, overwrite it, or ask the user for a new file name. This is done upon the first opening of the file. This is indicated by a "chk-exists" flag. The user replies to any of the above options. In the case of appending, the generic recorder 8b must erase the end of file record from the file to which the current
  • recording sessions data is to be appended. This is easily done for this is a fixed length record.
  • the session is then added to the file, ring buffer segment by ring buffer segment, one at a time.
  • the overwrite option merely has the generic recorder 8b create a file on top of the existing file. In the case of a rename, the recorder turns off and then awaits the user to press the start record sequence to input the new file name. 5. configuration
  • the configuration program 18 is written in C and receives information from the generic recorder 8b through the DOS multiplex interrupt. This routine first inquires for the residency of the generic recorder 8b and then requests the generic recorder 8b for the address of the configuration data structure that the generic recorder 8b uses for its operations. An INIT function then reads the FTF file 14, defaulting to a FTF file extension, as is more fully discussed below.
  • FIG. 7 shows the possible states of execution for the generic recorder 8b. Being a state diagram, FIG. 7 does not describe process and data flow. Rather, it shows the various states in which one might find the computer 6 after the generic recorder 8b is started. Transitions between states are indicated by the arrows on FIG. 7.
  • the disk symbol CFG FTF File 172 is not a state, but it is placed on FIG. 7 to show that configure 174 requires
  • These states may be generalized to configure, target program execution, recorder interrupts and recorder cleanup. Very little of the code is straightforward, linear execution of code in the normal DOS environment.
  • the interrupt states lend a level of complexity to the system that demands exacting care.
  • configure state 174 Based on data from the CFG FTF file 172, configure state 174 performs the following tasks:
  • the target program state 178 is entered after configuration 174.
  • the target program state 178 runs as in the regular DOS environment 176, except during the keyboard interrupts 180 and the hardware clock interrupts 182.
  • control is first sent to the recorder's keyboard interrupt routine. The actions that may be performed are: (1) nothing, the recorder is not activated; (2) recognize the activation key sequence; (3) store away the character generated from the keyboard; and (4) post an I/O cycle for the clock interrupt at 182.
  • the generic recorder 8b moves from the target program 178 to the clock state 186. From this point, the actions that may be performed are: (1) nothing, the recorder is not active; (2) compare the screen to its previous state at 188; (3) store the present screen; and (4) perform a disk I/O at 192. Wait disk I/O legal 190 is a state in which the recorder may not perform disk access because some other non-interruptible process is incomplete within the personal computer 6. An example would be that the computer 6 was serving a disk I/O request from the target 4 application when the clock interrupt occured. The generic recorder 8b must delay until it is legal to perform the disk I/O request.
  • FIG. 8 shows the data flow and memory organization between the configure state 174 (while an INIT program 194 is running) and the resident recorder 196.
  • the INIT program 194 reads a specified FTF
  • configuration file 14 from a disk of computer 2.
  • INIT 194 engages compile routines 200 to compile configuration data and key configuration table data and to insert them into the memory of resident recorder 196 at CFG data 202 and key KFG table 204, respectively.
  • the resident recorder portion 196 performs the recording task chiefly through the keyboard interrupts at 206 and clock hardware interrupts at 208.
  • the CFG data 202 tells the interrupts when it is necessary to record the screen to the data file 10.
  • the compress format box 212 represents the previously discussed ring data buffer.
  • the ring data buffer is written to the disk at disc I/O 214, and guided by the stored data path information at 216.
  • the start-up prompt 218 is a screen with the file name request field that appears at record start-up.
  • the first pointer is the beginning of the next write to disk. This is the data at risk.
  • the system begins the write to the disk file 10 at this mark. The next is, of course, the next write into buffer
  • This pointer is the last valid information in the buffer and the end of the write to disk area.
  • the next pointer points at the last type character buffer in the ring.
  • the key CFG table 202 is the master table for interpreting keystrokes from host 6's BIOS. Due to the vast differences between machine keyboards, the BIOS keyboard interrupt routine is called by the generic recorder 8b keyboard interrupt routine. The resulting keystrokes interpreted by the BIOS are maintained within a separate ring buffer within the generic recorder 8b.
  • the scan codes are the same across both PC's and PS2's of IBM. The start-up sequences, however, must be decoded for each variety of machine. Machine recognition code is provided with a variable that contains the machine type and
  • FIG. 9 shows the generic recorder 8b divided into the four major parts: (1) monitored interrupt 222; (2) screen multiplex interrupt 224; (3) clock interrupt 226; and (4) keyboard interrupt 228.
  • the generic recorder 8b terminate-stay-resident portion 196 replaces several normal interrupts so that whenever the operating system calls these interrupts, the resident portion 196 will have an opportunity to examine them before they reach the operating system.
  • FIG. 9 describes the fundamental TSR recorder 196 operations, whether in its inobtrusive background state or in its active recording state.
  • the generic recorder 8b reacts whenever one of the interrupts listed in FIG. 9 is called by the operating system.
  • the resident portion 196 replaces the operating system interrupt with a call to a routine of its own from which it will chain back to the normal operating system interrupt.
  • several interrupts are grouped together in FIG. 9 as monitored interrupts 222, since these are examined by resident portion 196 only to see if they are active. This is because the generic recorder 8b must wait while the operating system is busy with a task involving the
  • FIG. 10 shows the logic of a general monitored interrupt 222. This control structure is placed into the print screen, video BIOS, and DASD BIOS to maintain the status of the screen.
  • FIG. 10 describes a section of code that is inserted into the aforementioned DOS interrupt vectors. The control transfer may be made to this segment of code through either a hardware generated interrupt 180 or a software interrupt 186 in the target program 178. Each of these routines has a status variable in the resident recorder 196. The status is set at stop 230 to mark that the interrupt is in the process of being
  • the service routine which was the original address within the vector table, is then called at stop 232 as if it was a subroutine.
  • the original interrupt service routine does the DOS, hardware, or target
  • the monitored interrupt 310 routine then marks the state of the particular interrupt as non-active at block 234 and returns at iret 236 to DOS or the target program 4, whichever was the calling agent.
  • These interrupts, DASD, print screen, and video BIOS are monitored because they are not reentrant and the recorder uses some of these functions. Thus, the recorder cannot execute some of its routines when these interrupts are active. Therefore, the generic recorder 8b must know when these interrupts are active and does so by checking the status variables that these monitors set at step 230 and reset 234.
  • FIG. 9 also shows multiplex interrupt 224 which is described in more detail in FIG. 11.
  • This interrupt will first check at branch 238 to see if the code issued is in the command code for the generic recorder 8b. If it is not, the normal multiplex interrupt routine is called at chain interrupt 240. If the code is the generic recorder 8b's code, the parameter sent to the interrupt will be interpreted. Existence test 242 sees if this code is already present and, if so, calls iret 244 to exit with a flag saying that the system is already loaded. The parameter being examined at branch 242 could instead be a return buffer command, which is tested at branch 246. If it is, inquiry is made at branch 246 as to the location of the buffer that will be used by the C code portion of the generic recorder 8b to fill in control values. However, if the parameter is not a return buffer command, there is simply an iret 250.
  • the third interrupt connection in FIG. 9 is clock interrupt 226, which is further detailed in FIG. 12.
  • the hardware clock interrupt routine is inserted into the hardware clock interrupt stream. All comparison work and screen recording is done within the C code. Most of the major processing is done during this clock interrupt 226.
  • the two major subsections of the clock interrupt 226 are process keyboard information 258, which is detailed in FIG. 13 and which is further detailed in FIG. 14
  • FIG. 16 describes a process flags function 302 subset of the C clock code 260
  • FIG. 20 describes the record screen 334 function.
  • FIG. 12 shows the flow of an assembly routine clock interrupt 226 that traps the system clock
  • a counter is set at step 252.
  • the counter referred to is an integer, single word, that is incremented every time this hardware clock interrupt occurs. This counter is used to track timing within the recorder 196.
  • the interrupt 226 routine then moves to branch 254 and checks if the clock interrupt is already being processed.
  • the clock interrupt 226 is called periodically whenever the 8253 timer chip generates an interrupt. This means that the hardware frequently will cause the
  • Branch 254 prevents the routine from re-entering while it is still being executed from the previous request by exiting back to the interrupt point at iret 262. If branch 254 returns a negative value, the routine moves to branch 256 and checks if the generic recorder 8b is turned on. If it is, the routine moves to step 258 process keyboard and then calls the C clock processing routine 260. If branch 256 returns a no, the interrupt routine is exited at iret 262.
  • the final interrupt listed in FIG. 9 is the keyboard interrupt 228, a detailed discussion of which is postponed until FIG. 21.
  • FIG. 13 shows process keyboard 258, which is called within the clock interrupt 226 to allow the generic recorder 8b to process any keyboard interrupt queued data.
  • This routine examines the configuration table in CFG data 202 so that generic recorder 8b knows how to handle any special key. Special handling includes ignoring and triggering recorded screens.
  • Process keyboard 258 then branchs at 264, which checks to see if a key is buffered. If it is not, process keyboard 258 returns at 266. If it is buffered, branch 268 checks to see if the key is specified in the configuration table of CFG data 202. If it is, then branch 270 tests whether it can ignore the key. If the key cannot be ignored, branch 272 tests if it is a function key. If it is a function key or if it can ignore the key, step 274 sets record wait to
  • branch 276 checks to see if the key is a type-in character key. If it is not a type-in character key, branch 278 tests if it is an ASCII character. If it is or if it is a type-in character key, step 280 records the key and loops back to branch 264. Otherwise, out of branch 278, the character is ignored while also looping back to branch 264.
  • FIG. 14 further describes record key 280, as shown in FIG. 13. This routine places a type-in in a buffer in the main ring buffer. The keys are recorded with a compatible format within the CBT 12. More
  • record key 280 tests for an auto exit- condition, where the cursor has jumped to a place not next to the last character typed. If yes, step 284 puts a tab function key in to close the previous type- in and opens a new type-in. If no, branch 286 tests whether to record a type-in buffer. If not recording a type-in buffer then, step 288 sets up a type-in header. Otherwise, branch 286, or the output of stop 288, leads to branch 290 which checks for a type-in position flag. If the flag is on, step 292 gets the position from the compare screen routines subsequently discussed.
  • step 294 the cursor position is obtained from the hardware.
  • step 296 records the key and location, updates buffer size, then exits at return 298.
  • the clock interrupt 226 of FIG. 12 is shown with more detail in FIG. 15.
  • the clock interrupt 226 is divided into an assembly code jacket which sets up the C code environment and stack described above as FIG. 12 and the C code in FIG. 15.
  • the C code manages the compare routines and recorder control flags. The flag management is detailed in FIG. 16 and the screen comparison routines are detailed in FIGS. 17 and 18.
  • the C code clock interrupt routine 260 in FIG. 1 The C code clock interrupt routine 260 in FIG.
  • the clock routine 260 begins at branch 300 to test for any flags . See FIG. 16 below. If there is a flag, the recorder 8b proceeds to step 302 to process the flag(s). Otherwise, or if no flag or flags at 300, the recorder tests for, waiting for record, at branch 304. Waiting for record is a flag that indicates to the recorder 8b that a condition exists that requires the recording of the screen into the ring buffer. However, to prevent partly changed screens from being recorded, this integer counter is decremented for the FTF File 14 specified time 304, either in min/max fashion 328 or holdoff fashion 316.
  • the recorder 8b proceeds to bump the sample rate count at step 306.
  • the sample rate counter is used to count the number of clock interrupts that must occur between examinations of the screen to detect changes.
  • the sample rate interval in clock ticks is specified in the sample rate variable in the FTF configuration file 14. This prevents the recorder from using too much of the personal computer 6's processor time while waiting for the target application program 4 to perform some action.
  • the recorder 8b checks whether a time to check the screen has been specified at branch 308, and if not, returns at exit 310 to the calling assembler routine at FIG. 12.
  • the recorder 8b calls the screen different test 312b, which is described in detail in FIG. 17.
  • the screen different test 312b compares the current video refresh memory with a copy of the last recorded video refresh memory, and inquires about a different. If no difference is returned, the recorder 8b returns at exit 314 to the assembly routine at FIG. 12, and otherwise proceeds to branch 316 before a return at exit 320.
  • the set wait to holdoff step 318 is defined in the FTF configuration file as the elapsed time for the recorder 8b to wait once a screen change has been detected via screen different 312 (FIG. 17).
  • the recorder 8b proceeds to step 322 to decrement the wait count.
  • the C clock interrupt routine uses one wait count variable for delaying all screen records. This is done for simplicity. Once the system is in a state where it is delaying for the screen to be recorded (to inhibit intermediate screen
  • this integer variable is decremented at step 322 to zero and then the screen record is executed.
  • the recorder 8b proceeds to branch 324 where, if the
  • the recorder 8b returns at exit 326. Otherwise, at branch 328, the recorder 8b checks if the minimum/maximum routine is active. If active, the recorder 8b checks if it has waited for max at branch 330. In the case of min/max, the elapsed time is set to max after min is waited. When the screen is the same, which is determined by screen
  • Screen different 312 appears twice in FIG. 15 to illustrate that it is the same routine, called at different places, with different logic output controlled by its input. If the screen is different at point 312a, the recorder exits 332 without recording the screen. If a no is returned from 312, 328, or 316, or a yes at 330 (which means the screen has continued to change until the maximum time has
  • the recorder 8b records a screen at step 334 and sets the counts to zeros at step 336 before exiting at 338.
  • a screen comparison is performed at 312 if the sample rate has elapsed. At that time, the screen will be recorded at 334.
  • this routine sets the ring write flag to true.
  • the assembly code then performs the checks necessary for disk I/O. If the checks affirm that it is possible to write to the disk without interfering with DOS, then the write ring routine is invoked. Otherwise, the buffer will not be written till a subsequent clock tick or keyboard press.
  • FIG. 16 details the process flags step 302 of FIG. 15, i.e., flag processing during the clock interrupt 260.
  • FIG. 16 depicts the actions taken when control flags are set. If any flag is on, then the C clock interrupt 260 process flags 302 code is executed. This code is part of the C clock interrupt 260 code. Thus, all returns made in FIG. 16 are to the calling assembly code.
  • the major flags that are considered are the user request end record, write data buffer ring, buffer
  • overrun, user file name request, and user file exists flags The last two flags are used to get file name information from the user.
  • the overrun flag is set whenever information may be destroyed in the ring buffer before it is written out to the disk file 10. The overrun condition is when the recorder tries to place more
  • the ring buffer is filled by recording screens at step 334 and keystrokes (FIG. 20).
  • DOS is a single tasking operating system and does only one
  • the process flags 302 routine proceeds to check for a done flag at branch 344. Otherwise, at branch 340, the process flags 302 routine proceeds to the done flag branch 344. If user indicates that the recording should stop, via a keyboard interrupt done flag, process flags 302 returns via exit 346. Otherwise, the overrun flag is checked at branch 348, which is set as described above. If the overrun flag test returns positive, the buffer must be emptied; thus it is necessary to cancel all flags, set write ring to true, and return from 350 via 352.
  • step 370 creates a file and returns at 372.
  • FIG. 17 shows screen differs 312, which checks to see if the present screen is significantly different from the previous one.
  • the routine checks if the typing is in an ignore region of the screen by calling the tmp in ignore region at branch 382.
  • the screen differs routine exits at iret 384 and ignores the screen change. If the change was not in an ignore region, the new screen is saved at step 386. If the type-in position flag is set at branch 388, the character and its position are recorded in the small type-in ring buffers at step 392. Thereafter, 390 and 394 indicate returns.
  • IG. 19 details the tmp in ignore region 382 routine in FIG. 17 used to ignore a rectangular region of the screen. This region is dictated in the SYS
  • the region ignore may be triggered by a specific phrase appearing on the screen at a specific location.
  • Branch 414 checks for the specific string that should mark the beginning of an ignore region. If not found, the routine exits with a negative value at 416. If a qualify string is found, the routine checks if the changed character falls within the specified row and column range of the ignore region. If it is outside the row range, branch 418 returns a negative value and exits at 420. If outside the column range, branch 422 returns a negative value and exits at point 424. If the difference is within the ignore region (branches 414, 418, and 422 all return positives), the routine returns a positive value through point 426, and screen differs of FIG. 17 subsequently ignores the screen change and exits at 384.
  • FIG 20 Describes in more detail the record screen step 334 of C clock code at FIG. 15.
  • This routine checks the type-in mode at branch 428 and if active, allows the routine to finish the typing input at step 430. Once finished, the header and screen data is re-ordered at step 432 in the buffer for saving. If a 40 column screen is being recorded, the routine exits at 436. If an 80 column screen is present, step 430 reorders the second header and screen and exits through 440.
  • FIG. 21 is the keyboard interrupt 228. This interrupt is monitored first for the "on key" sequence. When this sequence is detected then the interrupt sets the flags to start recording and to query the user for the file name. Once recording, characters are buffered by the keyboard interrupt and then examined by the clock
  • step 442 gets the BIOS pointers; and then step 446 calls the BIOS and branch 448 tests for an key up. If yes, iret from the interrupt all release key interrupts are
  • branch 452 tests to see whether to dump the character. If yes, branch 454 tests if the ROM code is in use. If it is, then step 456 replaces the BIOS pointer. If it is not, then there is returns at iret 462. Branch 458 tests if the character is in the handler. If it is, then there is a return at iret 460. Otherwise, branch 464 tests if there is a shutting down request. If there is, then branch 482 tests whether to write the request. If yes, step 484 calls write A to disk routine, then returns at iret 486. If no, branch 466 checks if the character is turned on in branch 466. If it is not, branch 468 performs a single screen request.
  • step 470 set flags for single screen, then returns at iret 472. If yes, branch 474 checks for a turn on recording request. If there is none, there is a return at iret 480. If there is, branch 476 set flags for recording, then returns at iret 478. If step 466 returned yes, then the system is recording. Step 490 checks for a turn off key sequence request. If yes, step 492 set flags to shut down, then returns at iret 494. If no, branch 496 checks for a BIOS OK. If there is none, then step 498 brings on a translate key. Either way the key is then recorded to a small temporary buffer in step 500 where it will be processed by the next clock interrupt. The write request flag is then checked in branch 482, and the write routine called in step 484, etc. 7.
  • the CBT 12 code Since all the keystrokes and pointer selections are handled in a control loop outside the functions, the CBT 12 code must keep track of where it is at any moment so that on return the information received can be
  • the author menu 20 is page 1.
  • the author menu 20 When the system starts initially or returns from completing a task, it usually finds its way back to the author menu 20 or page l state for authors (again note that students have their own first page which they see at start-up and they never have access to the author menu 20 or the authoring functions).
  • Page 3 handles the defaults (F10 off the author menu 20). There are two screens in this mode, one for the session drive and automatic mode time delay, and the other for the super password, default time display, disk drive, light pen adjustment field, and printer type.
  • Page 4 is the single screen utility 56 mode (F7 off the author menu 20), much like the modify 46 mode for an exercise, but has some special differences. It is, in effect, a one screen work area into which one can bring in, change, and save a single screen. Page 4 is used for the modification of control screens by developers, and for the creation of QSCRs by authors and developers. Two additional submodes (color-ASCII 54 and options menu 52) are available in page 4.
  • the remaining page state is zero and it holds the states and substates involved in selecting and playing back an exercise.
  • Each of these additional states for page zero has a flag value to determine if it is
  • the student registration page is a one screen state that is flagged by whether or not p_Reg_Page is set.
  • the author menu 20 comes up with the following choices:
  • a QSCR could be defined as a screen which is added to the recorded pathway since almost every added screen is a QSCR. They must have QSCR in the first four characters in the upper left hand corner of the screen
  • the selection error messages are stored automatically as QSCR 2.
  • the screen that allows selecting the mode to run an exercise for the student is a QSCR 4.
  • QSCR X is the exercise statement that students can review while doing an exercise by hitting the PgUp key. It will retrieve the last QSCR X that had been seen in the exercise. If none has been seen yet, it will do nothing.
  • the flag p_QSCR_X_Exists is set (first to three then to TRUE once the screen itself is saved in the temporary storage).
  • a QSCR P will show up in proficiency 30 mode only, whereas a QSCR P will show up in all modes but proficiency 30.
  • QSCR M will show up in manual 26 mode only, while a QSCR M will not be seen if the mode is manual 26 or automatic 24.
  • a QSCR A is automatic 24 only, a QSCR C instructional 28 mode only, and a QSCR B is seen only if manual or automatic.
  • QSCR N will not be seen by users in any mode (it is for authors making notes), while QSCR with no letter (QSCR blank) will be seen in all modes.
  • playback 22 in FIG. 2 recall that an exercise can be "played” in several modes.
  • the mode will determine what screens will be displayed and whether help or error messages will be shown.
  • the four basic playback 22 modes are automatic playback 24, manual playback 26, instructional playback 28, and proficiency playback 30.
  • An exercise may come with the acceptable modes attached to it from a management system. When selected from the course directory or from the author menu, the proper QSCR 4 screen with the available modes will be displayed.
  • CBTS4x.SCR with the x being a number from 0 to 7.
  • the screen will not show the characters to the left of each entry - - either (M), (A), (C), or (P) - - as they are printed blue on blue. They are there so the line can be pointer device selected - - the pointer device routine searches to the left for the parenthesis to read the proper option [(See routine Plpsrch in CBT1.C)].
  • What users do see is the bar, currently white on red although this can be changed in a control file called st0.pew, and this bar works going up and down by reading the attribute in the first position where an option description is written. This must be yellow foreground.
  • the proficiency playback 30 mode does not provide the user with any substantive assistance in the way of procedure lines or explanatory material and requires the correct answer or action be selected before the screen is advanced.
  • the number of correct answers is kept so that a score can be returned.
  • the other two options are different only in whether the computer or the user advances the screens without valid selection being a requirement.
  • One is manual 26, which requires users to pointer select or enter any function key to advance.
  • the other is automatic 28, where the system will run the screens with a specific time delay and highlight the proper choices as it goes along.
  • the impact of automatic 24 on playback 22 should be apparent (p_Select_Time is one variable tested to see if the mode is automatic).
  • the instructional 28 and proficiency 30 modes are referred to as the teaching modes and the effects of whether it is teaching mode or not are littered throughout playback 22.
  • the highest mode of an exercise must be completed for the student to get a completion flag for the exercise in their course directory and credit: for the exercise.
  • the code has an numerous conditional statements and blocks of code that may not be activated during any particular playback 22.
  • the first screen will find its way into the buffer that is ready for video display. If an error screen is affiliated with it, that error screen will have been read and staged in the error buffer (p_Err_Buf). Then the next screen is read and, normally, the process will be stopped as a flag indicating the first screen is a stopping place should have been encountered in header byte seven of the screen following the first screen.
  • This staging process is a key to the
  • each read fills a buffer pbuff and then has its header read into p_Tempbuff.
  • p_Tempbuff Depending upon the
  • the buffers ptbuff and p_Low_Buff house the screen displayed (they are filled and then copied to the screen such that the screen and the buffers both hold the same
  • the default screen size is expected to be 40-character so it takes two buffers to hold an 80-column screen. If an error message was found for the screen it would be moved from pbuff to p_Err_Buf and that would empty pbuff again so another read would be made. At the end, if along the way that stopping byte was found, the final filling of the buffer with nowhere to put the information is the end of this staging.
  • pbuff houses only one record and this means that an 80-column screen is only half-read when the user has stopped reading (the important part - - the header which will later tell that the user has an 80-column screen and needs another read - - is in pbuff).
  • Playback 22 the user has staged information in the various buffers and has data sitting in p_Tempbuff to further describe what's ahead. Now the playback 22 loop begins.
  • P_DISPLAY_1 This sets up the display of the screen on the video . It checks whether the screen will in fact be displayed (if, for example, it is a QSCR C it is not supposed to display in any mode except instructional and would therefore be skipped and jump the user past the remaining display routines. P_DISPLAY_2 Now the system actually puts the screen
  • P_PLAY_SEL_1 Basically timer tests.
  • P PLAY SEL 2 Displays the auto block highlight of the correct entry.
  • P PLAY SEL 3 Handles the intensity of the top and bottom lines, something handled differently by the host and CBT. This type of screen
  • P PROCEED 1 This tests the user's input.
  • P PROCEED 2 This is another time test.
  • P PROCEED 3 Timers and returns to handle what to do
  • the first is P_Play_Int (transferred into P_Int later) that handles the larger issue of what the user was when the user left (a zero means the user is starting for the first time). If the user is modifying, p_Play_Int will come in with a value of four and the user has an additional variety of locations the user may return to above and beyond those handled by P_Play_Int. There is another variable set when the user leaves called
  • P_Play_Int_Code which will identify the function to be reentered.
  • playback 24 where screen advances are at timed intervals.
  • the logic waits for the correct answer to be selected.
  • the logic waits for the keys to advance to the next screen in modify 44 mode.
  • FIG. 22 details playback 22 of FIG. 2.
  • Step 502 open file, opens the file for reading in the data. Open file leads to step 504 to load the big buffer bytes into RAM which reads in a large piece of the file 10 from memory to RAM of computer 2. Thereafter, step 504 leads to branch 506 which checks whether a working buffer is empty. If it is not empty then playback 22 proceeds to branch 508 where, if the record in the buffer holds an error record, the error record is detected. Playback 22 proceeds to step 510 to move that record from the working buffer to error buffer, and then to step 512 empty working buffer so that the buffer can be refilled by the next record. Thereafter, playback 22 proceeds in a loop back to 506, the branch which determines whether the working buffer is empty.
  • step 514 determines if there is a typing record. If there is, playback 22 proceeds to 516, a step which moves the working buffer data to the typing buffer, and then loops back to branch 506 via step 512 as shown in the FIG. 22. With further regard to the branch 514, if there is no typing record, playback 22 proceeds to branch 518 which checks whether a virtual screen buffer, which houses the basic page 47, is empty. If the buffer is empty, playback 22 proceeds to step 520, which moves the working buffer data to the virtual screen buffer because, if it is not an error or typing, then it must be a basic page. Thereafter,
  • playback 22 again loops back into the program via step 512. However, if branch 518 determines that the virtual screen buffer is not empty, then all buffers are full, there is no place to store data. Thus, it is now
  • Playback 22 then proceeds to step 522 process playback record which is discussed below. Thereafter, playback 22 proceeds to branch 524, which checks whether the current working buffer data holds the last record flag indicating the exercise is at the end. If the record was set, then the CBT 12 returns to the program at 526. The loop at 506 will read data into the working buffer and find it's proper buffer (error, typing, virtual screen), until the virtual screen buffer is full, at which time that set of records is processed. At this point the next record is still in the working buffer. Thus, after process playback record 522, the next record header is checked for the last record flag. The error, typing, and virtual screen buffer flags are set to empty at step 528 and the process continues as the loop finds the next record in the working buffer when it returns to 506.
  • branch 524 checks whether the current working buffer data holds the last record flag indicating the exercise is at the end. If the record was set, then the CBT 12 returns to the program at 526. The loop at 506 will read data into the working buffer and find it's proper
  • FIG. 23 shows a more detailed explanation of the process playback step 522.
  • the CBT 12 begins with step 538, which tests whether or not to display, as some screens are not displayed depending on the playback 22 mode or user type. With respect to 538, if the answer is no, then the program goes via return 542 back to the program as shown in FIG. 23. Otherwise, at 540, the CBT 12 proceeds to step 544 to move the virtual screen buffer contents to the screen, as is more fully described below. Thereafter, the CBT 12 proceeds to branch 546 which tests whether the tutorial is being played back in the automatic mode. If the answer is yes, the CBT 12 proceeds to automatic playback step 24 and then onto return 542.
  • the CBT 12 proceeds to determine whether the playback is in the manual mode. If the answer is yes, the CBT 12 proceeds to step 26 manual playback and then onto return 542. Otherwise, at branch 548, the CBT 12 proceeds to branch 550 to determine whether it is being played back in the instruction mode. If the answer is yes, the CBT 12 proceeds to step 28, instructional
  • the CBT 12 proceeds to branch 552 to determine whether it is being played back in the proficiency mode. If yes, then the CBT 12 proceeds to step 30 proficiency playback 30 and then onto return 542. At branch 552, if a negative is returned, then the CBT 12 proceeds to query whether to enter the print mode. If the answer is yes, the CBT 12 proceeds to step 42 to commence printing and then onto return 542. At branch 28, if a negative is returned, the program proceeds to branch 556 to determine whether enter the modify mode 44. If the answer returned is yes, then the CBT 12 proceeds to step 44 modify and then onto return 542. If the answer
  • step 558 is reached. If this happens, there must be an error condition which is processed, and then the program moves to return 542. a) Automatic Playback (Page 1 F2)
  • the function will set p_Select_Time to whatever value is in p_Select_Timel or to 0.
  • P_Move_5 reads the block and automatically display any typing, and P_Play_Sel_1 will set a timer interrupt and return until that automatic time delay has been met (the logic sets pseudo interrupt P_Play_Int to 1 and when playback 22 is called again, that interrupt sends the logic back to this function to check the clock again). There is a final return to the last step in the playback 22 loop, P_Proceed_3, before displaying the next screen. This is to be sure that nothing critical is happening in the control log that requires attention.
  • FIG. 24 details the automatic playback step 24.
  • the CBT 12 commences with a wait time step 560, which causes the program to wait the time delay specified in this automatic playback mode before proceeding to the next screen. Thereafter, the CBT 12 proceeds to branch 562 to determine whether this screen has a user selectable item i.e., if it is in playback 22 in instructional or
  • this mode is selected from the QSCR 4 choices. By selecting 1, Psnot4ck sets the key variables. If called from the author menu, however, the name of the exercise desired to run is in the exercise name field on Page 1 and the required flag is set by calling
  • P_Automatic_Playback in CBT7.C. PPlaybck is called as the last option in P_Automatic_Playback and the user is on his way.
  • FIG. 25 provides the details of step manual playback 26.
  • the CBT 12 proceeds to step 568 to wait for any user input.
  • the screen will change on any user input. It will wait as long as the user wants (unlike automatic playback 24, which plays back in a fixed time interval) before cycling to the next screen.
  • the CBT 12 proceeds to branch 570 to determine whether the input is a selectable item. If it is not a selectable item, the CBT 12 proceeds return 572. However, if a selectable item has been entered at branch 570, the CBT 12 proceeds to step 574 to put highlight block on correct choice (see discussion of FIG. 27 above).
  • FIG. 26 provides the details of step 28,
  • step 576 display procedure line. If procedure line exists, as in instructional mode an extra line of 'advice' is often put on the screen for help, it is displayed. Thereafter, the program CBT 12 proceeds to branch 578 which determines if a type-in record exists. If yes, the CBT 12 proceeds to step 580 get and test type-in, which has the user input the typing, and the program test it against the expected response on file. Thereafter, the CBT 12 proceeds to branch 582, to check the result of the test. If the answer is no, (the response is not correct) then the program CBT 12 proceeds to 584, error count, to see if the maximum number of incorrect attempts has been reached. If this is not the case, then the flow proceeds to step 586 display appropriate error level, where it displays the error message and increments the number of errors.
  • CBT 12 loops back to step 580 get and test type-in. However, if an affirmative answer is returned at branch 584 (that is, the user has exceeded the max number of attempts), CBT 12 proceeds to display the correct answer at step 588, and then loops back to 580 again to have the user enter the correct answer now displayed.
  • step 590 can be exited by entering a correct answer at branch 582 which, like returning a negative answer at branch 578, leads to step 590 get test action key which is the function key or pointer selection that is required to take the next action which gets the next screen.
  • Step 590 leads to branch 592, which tests the input for the right answer. If a no is returned at branch 592, the CBT 12 proceeds to branch 594, to check to see if the maximum number of incorrect attempts has been reached. If a no is returned at 594, the CBT 12 proceeds to step 596, to display appropriate error message, and increment the error count, and loop back to step 590. Alternatively, if the number of incorrect answers reaches its limit, an
  • Instructional playback 28 then loops back to step 590, and can be exited by returning a yes at branch 592 which leads to return 600. d) Proficiency Playback
  • step proficiency playback or test mode 30 The flow proceeds to branch 602 to see if a type-in record exists. If an affirmative answer is returned, the CBT 12 proceeds step 604 to get and test type-in. Thereafter, the CBT 12 proceeds to branch 606. If it is not the correct answer at 606, the CBT 12 proceeds to branch 608 to ask if this is the first error made in this selection. If a no is returned, then the CBT 12 proceeds to branch 610 to ask if the error count is the maximum for this item. If a yes is returned at 610, the logic proceeds to quit 616.
  • step 610 the CBT 12 proceeds to step 614, to display an appropriate error message and increment the item error count.
  • the logic then loops back to step 604.
  • step 612 the logic proceeds to step 612 to increment the maximum error count. Only the first error on an item increments this exercise error count because an error on a particular selection should only count as one error in the exercise, even though there may be multiple errors made on that single selection.
  • the program then moves to step 604 to continue looping.
  • step 620 to test the action key for the function key or pointer hit required to advance to next page. This step leads to branch 622 to verify the user input as correct. A negative answer returned at this branch will lead to branch 624, to check if this is the first error of this selection. Again incrementing the exercise error total only once but allowing, in branch 632, for more than one error on the item ' s specified error count . If a no is entered, the CBT 12 proceeds to branch 626, to check the error count max for this item. If a no is again returned, the CBT 12 proceeds to step 628, to display the
  • step 624 the CBT 12 proceeds to step 630, the maximum error count is incremented and then moves to the test at branch 632 of the max error counter. If a yes is return from either branches 626 or 632, because the user has exceeded either the max allowed item or exercise errors, the flow leads to quit 616. However, if a no is returned at step 632, the CBT 12 loops back to step 620 via step 628. This looping is exited at branch 622 by receiving a yes when a correct action key is entered, to lead to branch 634. At branch 634, the last record flag is checked to see if the end of the exercise has been reached. If it has not, the CBT 12 proceeds to return 636. Otherwise, the CBT 12 proceeds from step 634 to calculate and display score at step 638, before also ending at return 636.
  • Printing an exercise calls the playback 22 routine with some special flags set. The exercise will flash on the screen while printing, which is like the automatic playback 24 in that the system advances through the exercise on its own.
  • the CBT_Character_Trap function evaluates the keystroke. In this case, it ends up calling a function to handle page one activity and that translates the F5 to a 'P', which is interpreted in CBT7.C in the page 1 routine that handles the selections. This translation is to preserve an original implementation.
  • P_Move_3 will actually test p_Start_Page and p_End_Page and, if they have been set and meet the test, a print is required and the logic calls p_Print_This_One.
  • the error screens are read into p_Scr_Buff into fixed locations such that if there is a selection error it will always appear at a certain row on the printed page, a typing error at the following rows, and finally the page itself.
  • Each page is printed with header information.
  • FIG. 28 details the print step 42.
  • This step starts at step 640 and prints the screen on the printer device.
  • the CBT 12 checks to determine if an error message exists (i.e., was there data in the error buffer) at branch 642. If there is an error message, the error message is also printed by means of step 644. If no error message is determined at branch 642, or after the error message has been printed at 644, the CBT 12 proceeds to typing buffer 646. From this branch, a yes response leads to step 648 which prints typing buffer information. Thereafter, or if a no is returned from branch 646, the CBT 12 proceeds to return 650. 4. Modify (Page 1- F4)
  • information on any individual screen can be changed by typing in new information. Colors and graphic attributes may also be changed. The expected location of the pointer hit, the function key needed to advance, or any error messages may also be changed.
  • the user will set the p_Modify_Mode_SW to TRUE, p_Stop_Each_Screen_SW to TRUE, p_Repeat_Playback to FALSE, and p_Select_Time will be set to zero. The user is off to PPlaybck.
  • the basic page is the raw page (R). If there is typing, the typing error message state (T) is next.
  • the selection error page (B) is the more normal second mode to appear. Any extra edit pages would show up as (E). For the purpose of talking about pages, only an R type increments the page counter with the others being subsets of that R page.
  • P_Display_3 must also deal with page numbers and the row and column location of the cursor.
  • the logic is here that determines whether the page number needs to be incremented before display. In addition, this function also tests whether the page number has reached the end point of the go forward command (if end page is greater than the current one the logic keeps going).
  • P_Move_1 leads to the selection error mode. If there is such a mode for the screen and the user is stopping at each screen, the user will return to the control loop with p_Play_Int_Code equal to two for
  • P_Move_3 handles the print test - - recall that all printing is done like a hurrying modify 44 mode. If the page falls between the start and end page numbers, the page is printed.
  • modify 44 does not involve selection testing in any way so the P_Play_Sel and P_Proceed
  • F10 If F10 is depressed, the system will be advanced through any error and extra edits to the next raw page.
  • the F10 key activates a flag, p_Speed_Modify, that will keep the user going until the page is a raw page, at which time the flag will be reset to FALSE and the logic will stop at that display and wait for input again.
  • the END key If the END key is depressed, the logic will be put into a hurrying mode which is like a fast automatic display where the screens will all fly by until stopped or until the exercise reaches the end. A '+' or ESC will stop the hurrying. When END is depressed, it sets a hurrying mode which is like a fast automatic display where the screens will all fly by until stopped or until the exercise reaches the end. A '+' or ESC will stop the hurrying. When END is depressed, it sets
  • P_Play_Int_Code + 50 and p_End_Flag to TRUE. Then, in playback, p_Stop_Each_Screen_SW becomes FALSE and
  • p_B_F_Number is set to 10,000 to assure that the logic will head toward the end.
  • encountered - - word wrapping uses the discovery of a box character or the borders of the screen as the wrap border.
  • Control-V will center that 40 column screen in 80 column mode (a centered reduction).
  • Control-L will take the screen and reduce it and place it on the left side of the screen - - i.e., the 40 columns in 80 modes takes the first 40 characters of each line, leaving the other 40 for
  • F6 (or Shift-6)
  • the logic will be put into color/ASCII 54 mode where the color or graphic attributes can be changed and boxes can be built. This key toggles to turn on and off this mode (although ESC will also turn this mode off).
  • the last line of the screen will have a bar which, when F6 is hit, allows shortcuts for the color, graphic, or window options. For example, C may be hit to get the full color chart
  • Selecting F5 will bring up the light pen window which allows a change in the location of the selection that should be made to advance from the raw page.
  • This information will be the row and column of the pointer device hit if the information is within the valid screen rows on a page.
  • a 25 as the row indicates that the action can be a function key and the determination of which key is found on the window and placed into the column specification.
  • F5 can only be used when in selection error mode since the information it saves is, as noted before, information about the record before - - the raw page.
  • the row and column are incremented by one so users can see the count begin at one, not zero, for the top line. This is also the case whenever the cursor row and column are shown on the screen.
  • P_Blink_Marker handles putting into line one (actually line zero) the page number and the modify state name.
  • P_PutRC puts up the row and column location of the cursor.
  • Modifying is at the heart of the system because it is what allows pathways to be turned into planned, organized exercises.
  • FIGS. 29-34 provide a more detailed description of the modify 44 subsystem of the CBT 12.
  • FIGS. 30-34 describe in further detail various subparts of modify 44.
  • Modify 44 uses a .100 file for the screen data.
  • the linear "rewrite” is also the reason that all information passes from the .000 to the screen and then to the .100 file. Hence if choosing to modify and then hitting the END key advances to the end, all the .000 screens will flash on the CRT. Another key reason for this is that the modify routine will "correct" some deficiencies that might have occurred in processing a file. For instance, if an exercise screen was turned into a QSCR with an error message, the next modify would recognize the QSCR and skip the error message display.
  • FIG. 29 begins at entry point 44.
  • the initial step 652 of modify 44 is to wait for input from the user.
  • the program checks for the status of the options menu 52. If the options menu 52 is active, the program enters options menu mode 52, as is more fully discussed below. If the options menu 52 is not up, branch 656 checks the status of the options menu toggle key. If the toggle key is in the active position, modify mode 44 proceeds to step 658 to turn on the options mode menu 44. After the options menu mode 52 has been turned on, the logic returns to wait for more input at step 652.
  • the program proceeds to branch 660 to check the status of the print or forward flag. If the print or forward flag is set, the program moves on to branch 662 to see if a stop key or stop page has been reached. If this is the case, the program then returns to the wait for input step at 652. Otherwise, the program moves on to branch 664 to see if printing is desired. If the answer is yes, the program moves on to step 666 and prints a page or pages, as per the user's request. However, at this point this mode is processing one page at a time in a loop so that the first page is printed, and, if more pages exist to be printed, the flag for print or forward has been set.
  • modify 44 exits and returns at 670 to the point from which modify was entered.
  • the program continues to branch 672, where the program checks the status of the page advance key. At this section, the logic is testing for keys. If the key struck is the page advance key, that key will skip the error modes and go to the next basic page. There is also a key for advancing to the next mode which moves from the basic page 47 to selection error 48 or, if in
  • the mode advance continues through the exercise one mode at a time. More specifically, if the answer at branch 672 is positive, the program moves on to branch 674 and checks whether the multiple delete 48 or replace 52 modes are active. If the reply is yes, the program exits at 670 from modify 44 and returns to the point from which it was called. If the status at branch 674 is negative, the program moves to save 676 where a screen is saved before returning through exit point 670 to the point at which modify 44 was entered.
  • modify 44 moves to branch point 678 where the status of the mode advance key is checked. If no, the program moves to step 696 to check the color/ASCII toggle key at branch 696. Otherwise, the CBT 12 moves to branch 680 to check for a multiple mode. Delete, save, replace, etc., can be for more than one page and hence when selected, the user is placed into multiple mode. This mode is ended by hitting the mark key and appropriate actions are then finalized. If the response is yes, the logic moves on to branch 682 to check for multiple delete or replace 682 modes. If the answer is yes, the program leaves modify 44 through exit point 670. In the alternative, the program moves to step 684 which saves screen(s) and advances the page. Thereafter, the CBT 12 exits modify 44 through point 670.
  • the program if the program is not selected to run in multiple mode, it moves on to branch point 686 to check for an error message. If an error message is desired at branch 686, the program checks to see if the error mode has been completed. If it has not, the logic advances to the selection error mode 48, where the error message can be modified. After the execution of the selection error mode in step 48, the program returns to its original wait for input step 652. If the response at branch 688 is positive, or the status at branch 686 is negative, the program moves on to branch 690 to see if the typing error mode is to be selected. This is a routine for editing a typing error message. If the response is positive, the program moves to branch 692 to check if the typing error mode has been completed. If the program has already modified the error message, for this screen, the response is no, and the program moves on to step 50.
  • step 50 After executing the typing error mode of step 50, the program returns to the wait for step 652. However, if the response at branch 692 is positive, or the response at branch 690 was negative, modify 44 moves on to step 694. At step 694, the program executes a save, and then exits from modify 44 through exit point 670.
  • the typing mode 50 allows changing the typing that the user inputs or any typing error message.
  • modify 44 moves on to branch point 696 and checks the status of the color/ASCII toggle key. If the key is toggled on, the modify 44 moves on to step 54 in FIG. 29 and enters the color/ASCII mode. After executing step 54, modify 44 returns to the original wait for input step 652. If the color/ASCII key is toggled off, the modify 44 moves on to branch 698 to check if the escape key has been struck. If it has, the modify 44 moves on to step 700 and verifies the particular desire triggered by the escape key. Modify 44 proceeds to branch 702 to see if the escape has been verified. If the answer is yes, the program executes a quit through exit point
  • modify 44 moves on to branch 706 to check the status of the LPW action key. If the key is toggled on, modify 44 proceeds to step 58.
  • the LPW mode 58 as in FIG. 2, is entered. After the execution of step 58, modify 44 returns to its original wait for input step 652. If the light pen toggle key is off, from branch 706, modify 44 proceeds to branch 708 to check if a character has been typed. If no character has been typed, modify 44 returns to the wait for input step 652. If a character has been typed, however, modify 44 moves to step 710 which echoes the character typed at the cursor location on the screen. Once this has been accomplished, the program returns to the wait for input step 652. a) Options Menu
  • FIG. 30 describes in further detail the
  • FIG. 30 describes the various optional functions the user may employ to do editing. In general, this part of the program presents the user with a menu of various options and then accesses the various functions as the user chooses them.
  • the portion of modify 44 described in FIG. 30 allows the user to enter an option key, then executes the function triggered by that key, and returns to subsystem modify 44.
  • the options menu 52 which is displayed on the bottom two (if 80 column) or four (if 40 column) lines of the screen. This menu is on the screen when p_Err_Mess_Select is set to TRUE.
  • modify mode 44 if the user advances through the various stages past the raw page to the error modes, the user will have the error message and options menu 52 pop up at the same time.
  • P_Err_Mess_Options in CBT3.C controls the menu; with TRUE as a parameter it will put it up and FALSE will take it down. Along the way either the selection error window or the typing error routines will be called (depending on whether p_Type_Err_Mess is TRUE or not) though if no error awaits those routines will do nothing.
  • the menu can be light pen selected or chosen from a keyboard input of a plus followed by the letter of the choice as shown in the menu.
  • the plus part is handled by the versatile variable p_Select_SW which is set TRUE when a plus key is hit. Light pen selection will set that variable TRUE and send the character in the parenthesis down just as if the key had been hit on the keyboard. (The select switch is used for other options like page one choices where an F1 is turned into a plus one and
  • the P_Select_ SW variable stops the logic when the user is in modify and hits the END key - - this variable must always be reset FALSE to avoid having unexpected results when a key is hit).
  • P_Err_Mess_Options will do a little bookkeeping before handling the options selected. P_Err_Mess_Options tests the printer, sets off p_Delete_Screen_SW if on and the next key was not an F to verify the delete, and tests some conditions against the EndOfExe screen (the last screen message displayed in modify mode).
  • Option P is for printing, which will evaluate the start and end pages based upon the input entries sitting in those fields in the menu.
  • P_Setup_No_Print_Pages will see the start and stop pages and p_B_F_Number is set to p_End_Page_Nbr.
  • the flag p_Stop_Each_Screen_SW is set FALSE so the playback will continue on until the condition is met (i.e., the end page is reached). Then the p_Play_Int flag is set to four and the menu is taken off the screen.
  • Option L is the list directory which will display a directory based upon the file specification in the lower right hand corner of the options menu 52. A flag will be set indicating a directory is showing
  • Option R is for replace and will act differently on ScrUtil then modify mode.
  • Screen Utility 56 is really more like an import a single screen facility in replacing whatever was active or showing.
  • the function insert_Single from CBT18.C is called to display the file (screen) indicated.
  • any replace whether single or multiple, will follow the deletion of other screens.
  • temporary pointers are set to the existing file to restate the condition if the user decides later not to accept the replacement, and there is a return to playback 22 after taking off the options menu 52.
  • Replace is like a delete followed by an insert.
  • modify 46 replace will act on an edit_mode of R and simply not write the screens until the user indicates the stop place of the delete (using option M which follows).
  • Options S, or save acts upon the file name shown in the lower right corner of the options menu 52. If there is a single screen extension (like TDS)
  • Option F the delete screen option, allows the user to flag a screen for deletion. The first time encountered, F sets the p_Delete_Screen_SW flag to TRUE. It must then get another plus F or light pen F to actually call the function P_Delete_Screen. Any other key will reset the flag to FALSE and requires the user to select F again to start the delete. If delete, the directory will be reset (through a recursive call to this function with an L parameter).
  • Option G allows going forward in the exercise in modify mode. There are two options - - a number that will bring up to that page number, or an F# where # is the number of pages to be advanced (i.e., the user is on page six and, to go forward five pages, enters either F5 or 11).
  • the function P_Setup_No_B_F_Pages is called to set the ending page.
  • p_Stop_Each_Screen_SW is set FALSE so the exercise will run until the desired page (the ending page) is reached.
  • the options menu 52 is taken off and the variable watched is p_B_F_Number.
  • Options 0-9 and X will fall through into the insert section for a single insert of a screen.
  • the character will be placed in front of the word NEW to call a file called 4NEW.SCR for a blank 40 columns screen and is also +4 on the menu, or 8NEW.SCR for an 80-column screen which is set when the filename is blank - see function P_Setup_File_Name.
  • p_Make_QSCR is set to the character and insert_single will then be called in the insert option (see Option I, below ). If there is a p_Make_QSCR value that file will be called through the p_Get_Or_MAKE_QSCR function and the screen will be
  • Option I insert
  • the first part of the code will come from the 0-9 and X options above because those cases fall through to insert. If there is no proper single file extension in the file specification found in the lower right corner of the options menu 52, or it is not on a raw page, the system will return. Otherwise, insert_single in CBT18.C handles the insert. This inserted file is not a part of an exercise until the program moves past, where the file is written to the .100 file. In order to delete or save that screen and any possible changes to the file, the edit_mode value of I is retained after the insert.
  • Insert_Exercise wrote the inserted screens to the .100 file and in a manner not visible to the user. In addition, the screen that was displayed when the insert was selected will still be the one on the screen even if the insert is accepted.
  • the value of p_Play_Int_Code is dependent upon whether the insert is accepted or not, and in all cases the options menu 52 is their removed and exercise modification continues.
  • p_Speed_Modify set to true so the user can only advance and thereby delete from raw page to raw page.
  • the screen up at the start will be the first deleted.
  • a +D followed immediately by +M will delete just that screen and any affiliated screens (error and typing and extra edit screens).
  • Option M indicates the end of a multiple edit action - - replace, save, or delete.
  • edit_mode is R a number of .000 pages have been 'skipped' in the .100 file and the new single or multiple file will be inserted (using insert_single or insert_exercise) .
  • the page number for display must reflect the pages not written and the new pages written. If a user decides not to do the replace at the end, the pointers saved before are used to reinstate the condition before +R was hit. If
  • edit_mode was D the header information found in bytes 7-8-9 of the first screen deleted will be placed into the header of the first screen that is NOT deleted (the one which +M was hit from) since this information is always about the screen that precedes and the current one is now the one following, not the one(s) deleted. In addition, the page count is adjusted. Finally, if the edit_mode was S, a final P_Saveb call with parameter X is made so that a last record is placed at the end of the screens being saved thus far. The system then continues processing the current screen.
  • the edit_mode variable is used primarily in
  • an S will be read by the playback 22 routines to write a second copy of the output file starting from where the S was hit until an M is hit.
  • A, D, or R will flag the situation so that when it comes time to write the screen to the .100 file the write will not be done and an
  • the p_Tempbuff_Full flag must be set to FALSE to begin staging from the pointer
  • p_Tempbuff[2] must also be set to zero and p_Err_Mess_Waiting to FALSE, to avoid adverse impacts on how the restaging is done. The page number is then decremented and will be incremented again when the screen is restaged.
  • P_Setup_File_Name is used in the options menu to weed out certain improper conditions and then to set up both p_File_Name_file which is the file specification used for the processing and p_Save_File_Name_File which is the variable used for what is displayed in the lower right corner of the options menu 52.
  • DOS characters such as A-Z, 0-9, _ , -, and blank. If listing directories the asterisk and question mark are allowed. If not a developer the user can only have files with TDS or 000 extensions and 000 is allowed only if the option is R, I, S, or L. File names like .EXE or .COM are not allowed. This function also handles the list
  • the cursor movement on the options menu 52 is handled with the Cursor Table assignments with functions like P_Wrap_Table_Set in CBT3.C providing the start/stop values for p_Cursor_Table[]. These table values are used as offsets for positioning the cursor.
  • the program reads an option keystroke entered by the user at step 712.
  • the input keystroke is examined to determine which of the various option keys the user has entered.
  • Branch 714 checks to see if the option mode toggle key has been pressed. If the option mode toggle key is the one that has been entered, options menu mode 52 moves to step 716 which turns off the option mode. The logic then exits through return 718 to modify 44 at step 52 in FIG. 29. If the input key was not the option mode toggle key, the program moves on to branch 720, which checks if the program is in multiple edit mode. If the answer is yes, the program moves on to branch 722 and the part of FIG. 30 that describes the multiple mode functions. Branch 722 checks to see if the input is the marked end key,
  • the options menu mode 52 moves to branch 724, which checks to see if the function is the save mode. If this is the case, the program moves to step 726, where the save file is closed and the multiple flag is turned off. The program then moves on to step 728 and verifies multiple command, which is the last chance for the user to indicate the intent to make this choice, and then exits from options menu mode 52 through point 718 as previously described.
  • the program moves on to branch 730, which inquires whether the desired function is the delete mode. If yes, the program moves on to step 732, where the multiple delete flag is turned off, and then on to step 734. At step 734, the verify multiple command is
  • the program moves on to branch 736 and checks if the desired option is replace. If yes, the program moves to step 738 where the multiple replace flag is turned off. Then, at step 740, a new file is inserted, and, at step
  • the verify multiple command step is executed prior to a return 718 to modify 44. If the program is in multiple edit mode at branch 736, the mark end key has been pressed at branch 722, but the mode is not save, delete or
  • options menu mode 52 continues to branch 744, which also checks if the mark end key has been input. If the answer is yes, the options menu mode 52 returns through exit point 718, as previously described, i.e., to modify 44. If the mark end key has not been pressed, the program moves on to branch 746. At branch 746, the program examines the key entered at step 712 and asks if it is the exercise statement key. If the answer is yes, the program moves to step 748 where an exercise statement template screen is inserted. An exercise statement template screen is just a special screen that outlines the objectives of the exercise for the student.
  • the template screen is inserted at the spot in the exercise that has now been reached (i.e., the student is advancing in the exercise page-by-page).
  • step 748 the program exits from the option menu mode 52 through point 718, and returns to modify 44 at point 52.
  • step 746 if the input does not match the exercise statement key, the program moves on to branch 750.
  • branch 750 the input is checked to see if it is the blank 40 character screen key. If yes, the program moves to step 752, which causes a blank 40 column screen to be inserted. These inserts are being made into the tutorial screen file after being "moved" over to make room. Modify 44 reads the old file and then saves to a new file. Thus, insert is actually just writing to the new file 10. Then, when the next old file screen is read and written, the new file 10 is located in sequence after the previously inserted file 10. At the end, the new file 10 is given the name of the old file, thus deleting the old file 10.
  • step 752 has been executed, the program exits the options menu mode 52 through point 718 and returns to modify 44 at point 52.
  • step 750 if the input does not match the blank 40 character screen key, the program moves to branch 754.
  • the input is checked for a match with the delete screen key. If the delete screen key has been pressed, the program moves to step 756 to carry out the required function. Step 756 sets the multiple mode delete flag and saves the current pointers. The program then moves to step 758 where the exercises advance to the next page. After step 758, the program exits the options menu mode 52 through point 718 and returns to modify 44.
  • the options menu mode 52 moves on to branch point 760 and asks if the input key is the replace key. If the answer is yes, the options menu mode 52 moves to step 762 to set the multiple mode replace flag and save the current pointers. After this is accomplished, the options menu mode 52 moves to step 764. Step 764 tests the validity of the replacement file. At branch point 764, the options menu mode 52 asks, is the replacement a valid file. If the answer is yes, the program exits from the option menu mode 52 through exit point 718 and returns to modify 44 at step 52. If the replacement file is not a valid file, options menu mode 52 indicates this and returns to require reentry.
  • Branch 768 checks whether the input key is the save key. If it is, the options menu mode 52 moves to branch 770. Branch point 770 checks to see if the file name entered, that is the destination file for the save, is a valid name. If it is, branch 772 asks whether the file name is an exercise file name. Exercises are files with an extension tacked onto the name (.000). However, the user can automatically save single screen 774 which are not exercises but which are files. If the user saves using a single screen name, it is not necessary to set a multiple flag.
  • step 774 sets the multiple mode save flag. From step 776, the program advances to the next page of the tutorial at step 778. The program then exits from the option menu mode 52 through exit point 718 and returns to modify 44.
  • Branch 780 checks to see if the input key is the insert key. If the answer is yes, the options menu mode 52 moves to branch 782 to see if the input file name is a valid file name. If the file name is not valid, like replace, options menu mode 52 would show the error in name on the screen. If the file name is valid, branch 784 checks to see if the input file name is the same as the exercise file name. If not, the options menu mode 52 moves to step 786 which inserts the present screen into the file identified by the file name. The options menu mode 52 then exits at exit point 718 and returns to modify 44. If the response at branch 784 is yes, the options menu mode 52 continues to step 788. Step 788 inserts the screen into the exercise file and saves the current pointers. The options menu mode 52 moves on tor step 790, where a verify multiple operation is conducted, and after completion, returns to modify 44 through exit point 718.
  • the options menu mode 52 moves to branch 792, which checks the input to see if the list directory key has been struck. If yes, the options menu mode 52 moves to step 794 and builds a directory from the file specification and displays it on the screen. After the directory has been displayed, the options menu mode 52 exits through exit point 718 and returns to modify 44.
  • the options menu mode 52 moves to branch 796 to check for the go forward key. If the input key matches the go forward key, the options menu mode 52 moves to step 798, which evaluates the number of pages to advance and sets the advance page flag. After this is accomplished, the options menu mode 52 exits through exit point 718 and returns to modify 44 at step 52.
  • step 802 sets the number of pages to print by setting the appropriate flag. After step 802, the options menu mode 52 exits through exit point 718 and returns to modify 44.
  • the options menu mode 52 advances to branch 804 to check the input key to see if it is the delete file key. If yes, at branch 806, the options menu mode 52 asks if the specified file exists. If the file does exist, branch 808 asks the user to verify the delete. This extra step prevents any accidental deletions caused by the user.
  • step 810 deletes the file from the file directory. After the file has been deleted or if the responses to branch point 806 or 808 were negative, the options menu mode 52 returns to modify 44 through exit point 718.
  • Branch 812 checks to see if the directory list is up on the screen. If yes, the options menu mode 52 moves to branch 814 and asks if the key is a valid list mover. If yes, the options menu mode 52 moves to step 820 and moves the list highlight bar. After completing step 820, the options menu mode 52 leaves at exit point 718. If the response at branch point 814 is negative, branch 816 checks to see if the input, usually the enter key, is to make a selection from the directory list. If the answer is yes, the options menu mode 52 moves to step 818 where the selected choice is put into the file name slot. After step 818, or if the response to branch 816 was negative, options menu mode 52 exits through point 718 and returns to modify 44 at step 52. b) Modifying Screens
  • modify mode 46 and in screen utility mode 56 an author can modify recorded screens or create new screens. Once in modify mode 46 (p_CBT_Page is zero and p_Modify_Mode_SW is set to TRUE) or in screen utility mode 56 (p_CBT_Page is four), any page can be changed using special editing functions. The situation is that the screen has been displayed and input is now desired. If alphnumeric keys are typed, they will appear wherever the cursor is and wrap around will be in effect.
  • the standard creation of boxes and colors and graphics come from hitting F6 which will toggle the color/ASCII line across the last line of the screen.
  • the flag p_Clr_ASCII_SW will tell the user if the color/ASCII mode, as F6 is known, is on. With that area there are two flags for when the user is changing color or ASCII graphics characters, p_Color_Mode and p_ASCII_Mode, that determine whether the respective window is on the screen.
  • color/ASCII mode 54 although ESC or an F2 for options menu 52 can also take down, restore, or leave these modes.
  • the current color and attribute can be found on the first line of the screen just after the row and column. They are placed there when the function P_Put_RC is called.
  • P_Put_RC When the user is entering color/ASCII mode by hitting F6 or Shift-6, the 25th line display is shown which has the current most logical colors displayed with the numbers 0-7 along with the letter key codes for other options like C to see the color chart and S for
  • P_Line_Box sets the current cursor location character or graphic to the current active ASCII character code or the one reflected in the choice made from the possible choices on the 25th line, while Psetatt will set the attribute at the cursor location to the current color or the one reflecting the color number selected on the 25th line.
  • the coloring and lining of boxes, used in creating, painting, and erasing or removing things related to and within boxes, are also handled in this function.
  • the box functions must worry about start and stop locations and use the upper left and lower right corner markings to determine the box size.
  • the p_Color_Box_SW variable toggles whether it is first time in or not, just as p_Line_Box_SW does for the line routines.
  • the line box function is similar in operation with S for single and D for double lines and an R for blank border.
  • the S-D-R parameter is evaluated, in effect, with the second call which actually draws.
  • CTRL-L and CTRL-V combinations can have an effect on a 40-character mode screen being edited.
  • the screen mode is switched to 80 character mode and if the option is CTRL-L the original 40 will be flush left in columns 0-39. If the CTRL-V is chosen, the 40 are centered (hence in 19-59).
  • the function is
  • FIG. 31 is a more detailed description of the logical functioning of the selection error mode step 48 of FIG. 30.
  • the selection error mode 48 allows creating and editing error messages.
  • FIG. 31 explains how error messages are created and modified and how the screens containing the errors can be changed.
  • the selection error mode 48 From its call in step 48 in FIG. 30, the selection error mode 48 enters the flow chart of FIG. 31 through entry point 48. At this point, the selection error mode 48 saves the current screen at step 822.
  • the selection error mode 48 displays the error message and the options menu 52 window. Later, when an exercise is displayed via playback 22, the error message formed in step 824 will explain to the user what error has occurred, and provide the user with options as to how to proceed.
  • the program moves to step 826 and waits for an input keystroke. Once an input key has been struck, the program moves to branch 828 to see if the option menu error message has been displayed. If it has not, the program proceeds to branch 830 to check the status of the option message toggle key.
  • step 832 restore the option menu error message and return to step 826. If the reply at branch 828 is yes, or at branch 830 is no, the program proceeds to branch 834 to check the status of the advance key. If this key has been hit, step 836 accepts the present screen as it is displayed. That is, the user has finished changing error message or didn't make a change. After step 836 has been executed, the program exits the selection error mode 48 through exit point 838 and reenters modify 44 at step 48 of FIG. 29.
  • the selection error mode 48 proceeds to branch 840 to see that a valid option menu item has been selected. If a valid item has been selected, branch 842 asks the user if he would like to print the present screen. If the response is yes, step 844 prints the screen. After the screen has been printed, the selection error mode 48 returns to step 826 and awaits further input. If, at branch 842, the user did not want to print the screen, branch 846 and asks the user if he would like to save the present screen on disk. If the answer is yes, step 848 saves the present screen.
  • the selection error mode 48 returns to step 826 and awaits further input. If, at branch 840, a valid option menu item has not been selected, the selection error mode 48 moves to branch 850 and checks to see that a valid key has been pressed. If it has not, then step 826 gets a new input. However, if a valid key has been pressed, step 852 is where the input keystroke is processed, and the error message is changed accordingly. From step 852, the selection error mode 48 returns to step 826 to await further input. The selection error mode 48 automatically exits when the advance key is hit.
  • FIG. 32 details the typing error modify mode 50, which saves the current screen at step 854, which saves what will be 'replaced' by the window so it can be reshown or restored if user toggles into options menu 52.
  • This option allows the user to 'exit' the typing error message.
  • the CBT 12 proceeds to branch 860, where it checks if the options menu 52 and the typing message are on the screen. If they are not, branch 862 asks if the key input at step 858 is the options menu 52 toggle key. If yes, step 864 restores the option menu typing message and loops back to get input at step 858.
  • the typing error mode 50 proceeds to branch 866, which looks at the cursor to see if it is in a valid typing location. If it is not, mode 50 loops back to get input keys at step 858. However, if it is, the typing mode 50 proceeds to step 868 to change the type-in character by putting the input key onto the screen, and then loops back to get input keys at step 858. However, if a yes is entered at branch 860, the typing mode 50 proceeds to branch 870 to check if the advance key was hit. If the advance page or advance mode key is hit (see 'modify' keys) the user is satisfied with what is on the screen.
  • the typing mode 50 leads to step 872 which accepts the screen as displayed and leads to return 874. If a no is entered at branch 870, the flow leads to branch 876 which checks whether a valid key has been entered. If a valid key has not been entered, the program loops back to step 858 to get input keys. Otherwise, the typing mode 50 proceeds to branch 878, which allows the user to enter a value that will set the level of matching required for the type-in to be accepted. The author could specify that anything is an acceptable type-in or may specify up to an exact match with all letters exactly as intended. If a yes is
  • step 880 change level of accuracy required, which in turn leads back to step 858 get input keys. If there is a no at branch 878, the typing mode 50 proceeds to step 882 to process the key as a change in typing error message itself, that is, the key hit in step 858 was in the typing error message box and it is used to edit the message. e) Color/ASCII
  • FIG. 33 describes in further detail the functioning of color/ASCII 54 from FIG. 2.
  • the program enters the color/ASCII 54 from modify 44 in FIG. 29.
  • this function allows the user to modify the color or graphic components of stored screens.
  • Branch point 884 checks to see if the color/ASCII mode is already on. If it is, the program moves to step 886 and turns the color/ASCII mode off. The program then exits from this function mode through exit point 888 and returns to modify 44. Returning to branch 884, if the color/ASCII mode is not on, the program moves to step 890 and turns the mode on. The program then moves to step 892 and waits for an input keystroke. Branch 894 checks the input keystroke to see if it is the color toggle key. If it is, branch 896 checks to see if the color mode is on.
  • step 898 the color/ASCII 54 moves to step 898, turns on the color chart, and then returns to step 892 to await further input.
  • step 900 the color/ASCII 54 moves to step 900, turns the color chart off, and returns to step 892 to await further input.
  • the result at branch 894 is negative, the color/ASCII 54 moves to branch 902.
  • the color/ASCII 54 checks for the graphic toggle key. If this key was input, the logic moves to branch 904.
  • Branch 904 checks the status of the graphic mode. If graphic is on, the
  • color/ASCII 54 moves to step 906, turns the graphic chart off, then returns to step 892 to await further input. If at branch 904 the graphic chart is off, the color/ASCII 54 moves to step 908, turns graphic chart on and returns to branch point 892 to await further input. If the graphic toggle key was not the input key, the color/ASCII 54 moves from branch 902 to branch 910. Branch 910 checks the input character to see if it is the box character. If it is, the color/ASCII 54 moves to branch 912 and checks if the box start has been marked. If at branch 912 the box has been marked, the color/ASCII 54 moves to step 914 and draws a box.
  • the color/ASCII 54 returns to step 892, after marking the box start in step 916, to await further input. Note that the user hits a special key when in color/ASCII mode 54 to indicate that the user wants to start a box with that spot as the upper left corner. Because the box is now marked, the next time through, the box character will draw the box using the second spot as lower right. If, at branch 910, the input character is not the box character, the color/ASCII 54 moves to branch 918 to see if the attribute code has been entered, and if so moves the color/ASCII 54 to step 920. Step 920 changes the attribute at the cursor and advances the cursor one space.
  • step 920 the color/ASCII 54 returns to step 892 to await further input. If the input key is not the attribute key, the color/ASCII 54 moves from branch 918 to branch 922 to see if the graphic code key has been input. If it has, step 924 changes the graphic at the cursor to the active graphic and advances the cursor. After step 924, the color/ASCII 54 returns to step 892 to await further input. If, at step 922, the input key is not the graphic code key, the color/ASCII 54 moves to branch 926. Branch 926 checks for the
  • step 928 changes both the color and graphic at the cursor and advances the cursor. From step 928 color/ASCII 54 returns to step 892 to await further input. If the response at 926 was no, the color/ASCII 54 moves to branch 930. Branch 930 checks for the paint code key. If the paint code has been entered, the color/ASCII 54 moves to branch 932 and checks the paint start point. If the paint start has been marked, step 934 paints the marked area with the active attribute. After step 934, the color/ASCII 54 returns to step 892 to await further input.
  • the color/ASCII 54 moves to step 936, marks the paint start and moves to step 892 to await further input. If the paint code has not been entered, the color/ASCII 54 moves from branch 930 to branch 938. The branch 938 checks for erase code. If the erase code has been entered, the color/ASCII 54 moves to branch 940 and checks for the erase start marker. If the erase start has been marked, the color/ASCII 54 moves to branch 942 and erases the marked area. After the erasure, the color/ASCII 54 moves to step 892 to await further input. If at branch 940, the erase start has not been marked, the color/ASCII 54 moves to step 944 and marks the erase start.
  • step 944 the color/ASCII 54 returns to step 892 to await further input. If, at branch 938, the input key is not the erase code, the color/ASCII 54 moves to step 946. If the color/ASCII 54 has reached step 946, the input key is not a valid key within the C/A mode. At this point, the color/ASCII 54 returns to step 892 and awaits further input. Note that there is no space on the flow chart that will allow an exit from color/ASCII mode 54 past branch 884, the color/ASCII toggle key. However, in fact the logic actually leaves color/ASCII after every keystroke.
  • CBT 12 will react to any pointer hit, putting together the row and column, but before it can act the CBT_Pointer_Trap in CBT1.C will check whether the hit is valid to handle and/or whether the program should either process it or not. If the CBT12 is to process a light pen hit the user can evaluate it several ways. The CBT12 can simply look at the row and see if it is a valid row on the screen showing as in a selection from the exercise
  • the CBT12 can take the location and begin a search to the left top find the parenthesis and then take the character between parentheses as the selection, examples being found on the options menu 52 or on the Page 1 menu (handled by function Plpsrch in CBT1.C). To know what to highlight is often a case in CBT of looking for two blanks between choices.
  • FIG. 34 is a flow chart that describes in detail the change light pen modify mode 58 from FIG. 2.
  • Light pen modify mode 58 changes the action key to advance from a screen in playback 22.
  • FIG. 34 begins at entry point 58, which corresponds to step 58 from FIG. 29.
  • step 950 The first step in FIG. 34 is step 950, where in the light pen modify window is displayed on the screen.
  • step 952 After displaying the modify window, step 952 and awaits user input.
  • branch 954 checks to see if the input key is the escape key or the light pen modify toggle key. If it is not, branch point 956 checks to see if the input key is some other valid key. If it is not, the modify mode 58 returns to step 952 and waits further input. If at branch point 956 the input key is a valid key, the modify mode 58 moves to step 958. Depending on the particular key input at step 952, step 958 changes the action key or light pen location values accordingly.
  • step 958 the LP modify mode 58 returns to step 952 to await further input. If the input key is the escape or light pen modify toggle key, the modify mode 58 moves from branch 954 to step 960, which turns off the light pen modify mode, to exit at point 962 and returns to modify 44.
  • this function is a single screen option that allows users to create, change, and save single screens using screen painting and editing functions. These functions are effectively also available in modify 44 mode, except that p_CBT_Page is equal to 4, whereas in modify 44, it is equal to zero.
  • the Page 1 menu selection of F7 triggers the call to this function.
  • the logic begins by resetting the key to the RESETKEY (F7) and setting the Function_Key_SW to TRUE again, before calling the CBT_Character_Trap function. This time CBT2B.C does the page one translation and, if the user is not on page la, the logic turns the key into the SP2KEY. Thus, when the logic falls on down the line of calls in the trap, it hits the function key call, and finds that it is on page 1 with SP2KEY hit.
  • FIG. 35 describes the functions associated with the single screen utility 56 shown in FIG. 2.
  • the screen utility 56 allows the user to manipulate screens. These manipulations include changing the color or adding alphanumeric, or graphic characters to a screen so that the screen: could eventually be inserted as is in a tutorial file; or could be a template screen that would be inserted into a tutorial and then customized; or could be a system control file screen.
  • the utility 56 can also be used to add help message data to an existing screen.
  • Step 966 loads a default screen identifying that the user is in screen utility.
  • Step 968 displays the option menu 52.
  • the program moves to step 970 and awaits user input.
  • Branch 972 checks for the escape key. If struck, the escape key causes the program to abort the screen utility 56 function and exit through point 974. If the escape key has not been struck, the program moves to branch 976 and checks for the color/ASCII toggle key. If the color/ASCII toggle key has been hit, branch 978 checks to see if the color/ASCII 54 mode is already on. If yes, the program moves to 980, turns the color/ASCII flag off, and returns to step 970 to await further input.
  • step 982 the program branches instead to step 982 and turns the color/ASCII flag on. The program them returns to step 970 to await further input. If at branch 976 the color/ASCII toggle key was not struck the program moves to branch 984 and checks for the options menu toggle key. If the option menu toggle key has been struck, the program branches to branch 986 and checks the status of the option menu 52. If it is on, the program turns it off at step 988 and if it was off the program turns it on at step 990. After toggling the option menu mode either on or off, the program returns to 970 to await further input. If the input key was not the option menu toggle key, the program moves to branch 992.
  • Branch 992 checks if the color/ASCII flag is on, whereupon the program branches to 994.
  • Branch 994 checks if the input keystroke is a valid color/ASCII option key. If yes, the program proceeds to 54 and calls the function process color/ASCII. This is the same function as color/ASCII 54 shown on FIG. 2 and explained in the part of the
  • Branch 1002 asks if the input is a valid keystroke other than the keys examined in branches 972, 976, 984, 992, and 996. If the keystroke is valid at 1002, step 1004 displays the keystroke at the cursor location, and returns to step 970 to await further input. If at branch 1002 the input is not a valid keystroke, the program ignores the keystroke in step 1006 and returns to step 970 to await further input.
  • FIG. 36 is a flow chart describing the subfunction, process option, entered at point 1000 on FIG. 35. This function allows the user to perform a number of operations on the subject screen.
  • the flow chart is entered at point 1000 and proceeds immediately to branch 1008.
  • Branch 1008 checks to see if the input is the exercise statement key, and if so, moves to step 1010 and inserts an exercise statement template screen. The program then returns to step 54 through exit point 1012. If the response at branch 1008 is negative, the program moves to branch 1014 and checks if the input is the blank 40 character screen key. If yes, the program moves to step 1016 inserts a blank 40 column screen, and then returns to step 54 through exit point 1012.
  • Branch 1014 checks for the replace key. The replace keystroke, moves the program to step 1016.
  • Step 1016 checks to see that the present file name is a valid file name. If the file name is valid at branch 1018 the program moves to 1020 and inserts the named screen, replacing the current screen at that point in the file. The program then returns to step 56 through exit point 1012. If at branch 1018 the file name is not a valid file name, branch 1022 checks if the file name is blank. If the file name is blank, the program inserts a blank 80 column screen, replacing the current screen in step 1024. In either case, the program then returns to point 56 through exist point 1012. If at branch 1014 the replace key has not been struck, the program moves to branch 1026 and checks for the save key. If the save key has been struck, the program moves to branch 1028 and checks that the present file name is a valid file name.
  • step 1030 the program moves to step 1030 and saves the present screen in the specified file, before returning to point 56 through exit point 1012. If at branch 1026, the save key has not been struck the program moves to 1032 and checks for the print key. If the print key has been struck, the program moves to step 1034, and prints the present screen on the output printer. The program then returns to step 56 through exit point 1012. If the exercise statement key, blank 40 character screen key, replace key, save key, or print key have not been struck, the program will end up at step 1036. At this step, no legal option has been entered, so the program aborts the process option sub-function and returns to step 56 of the screen utility function.
  • the author or the developer may run the student subsystem from a diskette like the students by changing the session drive to A (using defaults - -F10 off the author menu 20) before running this option of F9 off the author menu.
  • P_Start_Student in CBT4.C is called. This will display the student start-up screen and set p_Reset to three and p_Temp_Student_SW to TRUE. It positions the cursor off the page and calls the control loop to await a keystroke.
  • That keystroke goes through CBT_Character_Trap, gets to P_T_Char_Process_Reset in CBT2B.C which will reset the p_CBT_Page to zero, set pdemof to 33, and call the registration page with P_Reg_Page.
  • P_Dir_Page_Was_SW The function P_Dir_Page found in CBT10.C is called. It displays the directory (note if returning from an exercise, the program would return to this area of PMasterm with the flag p_Dir_Page_Was_SW set so it would not get the directory again from disk but merely display by calling P_Dir_Page with a FALSE parameter). After display of a directory, the logic returns with the state P_Dir_Page_SW set TRUE.
  • CBT_Pointer_Trap will take the input and, with a valid selection, the user will be ready to go forward to the mode selection or QSCR 4 screen.
  • a selection on the directory page is handled by Process_Selection in CBT10.C and, if valid, the functions sets p_Dir_Page FALSE and p_Sn4_Page_SW and p_QSCR_4_SW to TRUE.
  • the exercise name is placed in the file
  • the QSCR 4 is displayed and the system waits for a keystroke or pointer hit.
  • the hit is evaluated and the character passed to the function Psnot4ck which sets the flags.
  • This function is called from CBT_Pointer_Trap or from CBT_Character_Trap based on p_Sn4_Page_SW being TRUE.
  • CBT_Pointer_Trap or from CBT_Character_Trap based on p_Sn4_Page_SW being TRUE.
  • the function calling Psnot4ck will also set p_Play_Int to four before returning above. This will cause CBT_Low_Interrupt to call the function that starts the playback - Pplaybck.
  • pdemof will be 33 and p_Dir_Page_Was_SW will be TRUE and the user can continue in this directory - exercise loop for as long as the user wishes.
  • CBT 12 provides a student registration page. Once the student hits the Enter key from the first introductory screen (or once the author/developer has used the F9 option the page one menu), the state of the system is identified by p_Reg_Page_SW being TRUE and the function P_Reg_Page is called. The majority of registration code can be found in CBT9.C.
  • the process begins by the reading of the
  • CBTREG.DAT This is an ASCII text file that can also come from the management system and is rewritten if the information is changed or entered for the first time (keep in mind that as an ASCII text file the rewrite requires an end-of-file hex 1A).
  • the p_Ident_Good flag is set to TRUE.
  • the registration page itself is then called from disk and displayed.
  • the information on file is filled in and the process of entering the data begins.
  • the cursor is placed on the password field where the user can enter the password and continue to the course directory. However, they could use TAB or arrow keys to update any information.
  • the system now captures keystrokes at the local level. However, it still needs to leave for help upon hitting Shift-F1 for help. It therefore sets up a global variable to hold the field that it was on when help was requested, and sets P_Play_Int to 88 so that on return to the Reg_Page function (it will come back due to the state) it will not reread the file or retrieve the screen again.
  • the input function is Full_Fill_In and will fill in the data (if the p_Play_Int was not 88) for all fields before going to the field sent down as a parameter for its first entry. There is a loop on the variable value that is incremented after each successful entry to bring one through the possible cases and, finally, to the password field.
  • Password entry is either a call to
  • p_Reg_File_900 array is reassembled using a sprintf with the temporary fields in the function build_reg_file, and then written out with a final CR,LF, and CTRLZ in
  • the P_Reg_Page function will set p_Reg_Page_SW to FALSE and pdemof to 33 and sends the user back though PMasterm. In effect, this will call the course directory (based on the value of pdemof).
  • FIG. 37 explains the limited mode of student interaction with the program, and this subsystem may well be provided to the students on a diskette separate from the rest of the program.
  • FIG. 37 commences with step 1038 which displays a first screen 1038, which is a welcome or introductory screen. After the first screen is displayed, there is a wait for a start-up key in step 1040.
  • This start-up key input leads to the load registration template screen 1042, in which the registration page with blanks where data will go, is displayed.
  • Step 1044 allows a student to load in registration data, including; name, ID, work number, and a password at the end.
  • Step 1044 leads to branch 1046 which queries whether the student has been previously registered by checking if any data already exists.
  • the CBT 12 proceeds to request registration data to be entered by the user in step 1048. This leads to branch 1050 which checks whether all the registration data has been successfully completed and entered. If it has not, then the program CBT 12 loops back to the display first screen 1038. Otherwise, if the user has previously been registered as determined in branch 1046, or has completed entering the registration data successfully as determined in branch 1050, the CBT 12 proceeds to entering a password in step 1052. Thereafter, in branch 1054, the password is examined to determine whether it is valid. If it is not valid, the CBT 12 proceeds through branch 1056 which counts whether there have been more than three errors entered in an attempt to provide a valid password.
  • the course directory is organized such that items are indented based upon their significance, and a highlight bar will only fall on those items that are the most indented - - the exercises themselves.
  • P_Dir_Page (found in CBT10.C along with most of the course directory code) will set the p_Dir_Page_SW TRUE so that whenever the user leaves for keystrokes the user will know where to return and what to do with the keys. It will then call the routine Copy_Course_Dir.
  • course_dir[] []. A count of the number of records is kept in recount to be used later for writing and for highlight bar movement when needing to know the end.
  • the valid keys to continue to process would be Up Arrow, Down Arrow, Page Up, Page Down, End, Home and Enter.
  • the CBT2B.C routines will call P_Course_Dir_Page and send down a character
  • the directory has the diskette number on which the exercise can be found sitting in byte 11.
  • the value of that byte is compared with the current header record value of byte 56 and, if they are not the same, the system will ask that the proper diskette be loaded. It does this by placing that 11th byte value into p_Exercise_Name and calling
  • P_GP_Mess_Display This will place the value into the proper spot on a message asking for the proper diskette number.
  • the directory When the message is displayed, the directory simply becomes active again as if no choice had been made and the user may or may not actually enter the proper diskette. The test would be made again when an exercise is selected.
  • Critiques are an exception here.
  • the critique flag (byte 66) is checked and if yes the system wants diskette one, even if the directory says it is on another diskette (it is added to the last diskette in the
  • Update_Status is called to start the exercise - - it puts in a start date if none was there, increments t ⁇ rer number of tries by one, and sets the timer.
  • the function is called with an L parameter where it puts in the time, a completion date if the mode done was the highest mode the exercise runs in (these go, in order, manual, automatic, instruction, and proficiency).
  • an ESC from the critique will mark all flags as if never called, including erasing the start date.
  • the directory When the user has finished with the directory and chooses to ESC, the directory will be written to the disk. If the proper disk is accessible the completion flag will be written to the temporary header array
  • This step commences by reading the directory file in step 1058.
  • the student disk is read for the directory of courses available on the specific disk. If multiple diskettes exist, the first (or diskette #1), should be used at start. Thereafter, the CBT 12 checks whether the proper diskette has been loaded at branch 1060. The program will only accept properly formatted student diskettes. If the loaded disk is wrong, a proper diskette is requested at step 1062, which loops back to read directory file 1058. If the diskette is the proper one, the CBT 12 proceeds to display the directory file on the screen in step 1064 and onto requesting student input at step 1066.
  • Step 1070 leads to read directory file which, when the st ⁇ dent disconnects from the host or application, will return then to CBT at the point of reading in the directory file again.
  • the CBT 12 proceeds to determine if an exercise has been selected at branch 1072. If the key selected at 1072 was to select an exercise off the
  • step 1078 moves the CBT 12 to branch 1074, which changes the location of the directory highlight bar. This just moves the highlighter to another location (valid keys would be Home, End, Page Up, Page Down, etc.). If yes at 1074, step 1076 moves the highlight bar as per the key and, thereafter, returns to get student input 1066. If a highlight move key is not entered, the invalid key - ignore step 1080 is reached. This step ignores what was an invalid input and loops back to read directory file 1058. If a yes is returned at branch 1072, the program proceeds to query whether the student desires to enter a critique using our special evaluation screens (one for each directory) at branch 1078. If a yes is returned, then the CBT 12 proceeds to step 38 critique, and
  • step 1086 display the allowable modes at this point in the program.
  • branch 1088 examines whether a valid choice was made. If a valid choice was not made, the choice is examined to determine if it was an escape key that was depressed. If the escape key was depressed, then the CBT 12 proceeds back to read directory file 1058. If the escape was not depressed, branch 1090 steers the CBT 12 back to step 1086 to allow the student to make a choice of mode. Once a valid choice has been selected as
  • the CBT 12 proceeds to step 22. At this point the program accesses playback 22 and runs through a tutorial session as explained above.
  • a critique is a special exercise selectable from the course directory that provides users the opportunity to rate the course they have taken. It is another of the possible links between the management and CBT 12 system in that information is placed into a special file in a special format for a management system to import. That file, CBTCRIT.DAT, consists of eight blanks (which used to hold an exercise name when critiques could be done on each exercise), a block of up to 50 bytes to hold the rating values of 1-5, and a final string to hold the generalized comments. As a basic ASCII text file it must be ended with hex 1A.
  • the critique consists of a variable number of pages, each page being a compressed screen file on disk named CBTCRITx.SCR.
  • the x is the incremented page number starting with 1 and currently ending with 4.
  • the first is loaded and processed and, upon completion, the number is incremented and the next page brought in.
  • the page consists of one-character fields which have braces around them and which have the special attribute defined as p_Field_Att_Req.
  • the cursor location routines then seek from where they start to the next spot that matches that attribute in advancing through the page. A value must be entered in order to leave one of these fields. It also stops on a p_Field_Att_Opt although this is only used for the comment field.
  • P_Crit_Page (found in CBT15.C) sets the p_Crit_Page_SW to TRUE (note that p_Reg_Page_SW remains TRUE also) so that any exit to the control loop for keystrokes will know where to return.
  • the function then reads the diskette to see if it is diskette #1 (the system wants diskette #1 to have the most recent data read and written).
  • the file name held in p_File_Name_csr[] is read in and the number 1 is added when the function is called for the first time (the parameter passed was TRUE).
  • the file (a screen) is then displayed and the cursor position set to 0,0 from whence begins the first search for a valid input field. That search is handled by the function
  • the cursor Normally, the user starts entering their ratings and the characters are tested to see that the number is between 1 and 5, with a valid entry causing the cursor call to advance to the next valid empty field location. The cursor stays put if the user is on the last field already and awaits a Return (the Enter key on the PC) to go to the next page. If the row is > 24 in the cursor location loop looking for a valid field,
  • p_Ok_For_Next_Crit is made TRUE. (If the user is on the comment field of the last page, an optional field, the user will be allowed to type in anything and arrows, backspace, and enter would allow movement there, although word wrap on the borders is not allowed.)
  • P_T_Char_Crit If p_Ok_For_Next_Crit, return will call P_Get_Next_Crit_Page is there is another page to retrieve. That function sets p_Ok_For_Next_Crit off again, reads p_Crit_Buffer in a loop until it hits a null to advance past any information entered on any previous pages, then reads in the screen fields and adds them to the array. A null is put at the end (ready for the next time this function is called to seek the first null), and finally calls P_Crit_Page with a FALSE parameter.
  • P_Crit_Page will now add one to the file name, load the new screen and display it, set the cursor at 0,0 again, and search for the first valid field (again using p_Req_Field), to be ready to process keys again.
  • P_T_Char_Fn_Key processing routine tests if for an F2 and a return value for P_Check_Reg_Field. If F2 and P_Check_Reg_Field returns set to true and p_Ok_For_Next_Crit, the system tests whether the user is at the last page. If so, the program will call P_Write_Crit_Data to complete the process. This test looks at the page information at the top of the screen to see if it is on the same page as there are pages i.e., the user is on page 4 of 4, and is thus at the end. P_Check_Reg_Field effectively checks that the required field has been entered into. The Up Arrow and Down Arrow keys do the literal movements.
  • the write function builds the output file by copying eight blanks to the start of critique_buffer, then adding in the P_Crit_Buffer array until a null is found. It then reads in the comment from the screen and adds a CR, LF, CTRLZ . Then the file is written by putc-ing the array critique_buffer.
  • Help system 44 is not field-specific but state-specific. It is based upon which state and mode flags are active.
  • the hotkey (Shift-F1) is evaluated as a very early part of CBT_Character_Trap in CBT2A.C.
  • P_T_Char_Start_Help is called and if the user is not in help mode and the hotkey was hit, a flag called
  • p_Start_Help_Soon_SW is set TRUE and the user returns up to the control loop.
  • Help system 44 checks that flag and, if TRUE, resets the flag and sets p_Help_Mode equal to TRUE. Pphelp is then called to display the proper help screen and then P_Get_Help_Fn_Char is called to process a help screen.
  • Pphelp in CBT15.C is called while in a help mode.
  • p_CBT_Page is used as a flag in that if the user is just starting help, the page is the normal zero to five, but if the user has a help screen up on the screen, the value is incremented by 10 so that it is 10 to 15. That 10 is added every time the help screen is displayed (and subtracted every time the loop where page is 10-15 is entered so that the proper page number is back when the time comes to evaluate states).
  • the file specification array pdhelp[] is filled with the first three characters based upon the state, followed by the number of the help screen in the sequence if more than one screen of help is available for the option, followed by the period and the file extension hip.
  • the current screen is then held in a buffer with a call to Hold_Screen and the help screen is displayed.
  • CBT_Pointer_Ok is set FALSE so the light pen will not be possible on help screens.
  • P_Get_Help_Fn_Char is called (located in CBT7.C) to setup the menu line for the option of Next, Back and Exit at its initial location and saves that in p_Save_Help_Fn_Char.
  • P_T_Char_Process_Help (again high in priority in CBT2A.C). If Enter is hit, the program will accept the current highlighted option Back or Next (the letter of which was saved in p_Save_Help_Fn_Char). Page Down and 'B' act the same, calling Pphelp with a back parameter. Arrows keys call P_Get_Help_Fn_Char with an N to move the bar to the proper next option highlight. An 'N' calls the next help page through Pphelp and again resets the bar to the initialized location through a call to P_Get_Help_Fn_Char. An 'E' or another Shift-F1 designates completion of help and calls Preturn found in CBT15.C. Preturn will set p_CBT_Page back to its normal state, p_Help_Page_Nbr to 0 again and p_Help_Mode to
  • FIG. 39 contains a flow of the sub-program search 44 of the CBT 12.
  • search 44 allows the user to search through a specified file for the occurrence of an input string.
  • the chart shows the logical flow from the input of the search string, the choice of search file, and through the actual search process itself.
  • the program enters the sub-program search 44 through entry point 68.
  • the first step 1094 inputs the user's search string or strings.
  • branch 1096 there is a check to see whether the input is valid. If there are no valid strings, the logic moves to step 1098, provides a message to that effect, and exits from the search subsystem through exit point 1100. If the input string is a valid entry, the logic moves to step 1102. In step 1102, the input is compressed to match the compression of the stored exercises.
  • the program then moves to step 1104 and asks the user to input a file specification. Branch 1106 checks for a valid file name. If no valid file name was input, the program moves to step 1108 and provides a no match message and exits through exit point 1100.
  • Step 1110 opens the search result output file.
  • Step 1112 tries to read the next file in the input file list.
  • Branch 1114 asks if the user is finished with the input files, i.e., has finished
  • Step 1116 reads in a header from a record in the input file.
  • the program then moves on to branch 1120 on FIG. 39b.
  • branch 1120 there is a check if this is the last record in the input file. If yes, the logic returns to step 1112 and tries to read the next file on the list. If the record examined in branch 1120 is not the last record in the file, the logic moves on to branch 1122. Branch 1122 examines the record to make sure that it is a basic page from a stored tutorial. If not, the logic moves to step 1124 to display an
  • step 1126 searches through the record for the input string.
  • Branch 1128 checks for the existence of a match. If there is no match, i.e., the input string was not found on the recorded page, the program loops back to step 1118 and inputs another record. If a match has occurred, branch 1130 checks for a second input string. If there is only a single search string, step 1132 writes the page and file name to output file. After the data has been written, step 1118 reads in another record. If there is a second input string, the program moves from branch 1130 to step 1134.
  • Step 1134 repeats the search of step 1126 using the second input string. If there is no match, branch 1136 returns to step 1118 to read in another record. If the second search string resulted in a match, branch 1138 checks for the existence of a third input string. If there are only two input strings, the program moves to step 1132 and writes out the page and file name data where the match occurred. If there is a third input string to search, step 1140 executes this search. Branch 1142 checks for the existence of a match, if the third string was not found, the program loops back to step 1118 and reads in another record. If all three search strings were found on the present page, step 1132 writes the page and file name data to the output file.
  • the program then loops back to step 1118 and reads in another record.
  • the program continues through this flow of reading in records and then searching them for the input search string, until the last record of the file is reached.
  • the program also cycles through all the input file names to be searched. Once all of the files have been searched, the user exits the sub-program search 44.
  • Selecting F6 on the authors menu will bring up the file functions menu. It sets a flag called p_Pagela to TRUE. For most processing, the state is still has p_CBT_Page equal to 1 and this is a subset of that. There are a only a handful of differences between 1 and la.
  • P_CBT_Pagel processes the options for both page 1 and la. It will call P_CBT_Pagela if on page 1 and the user hits F6. That screen will be displayed and the return is to the control loop to wait for the keystroke or action that will recall the P_CBT_Pagel, this time with the page la flag set so it looks at those options instead.
  • CBT2A.C that redefines the keys for page 1 in that an F5 translates to a 5 in page la, but because printing used to be something else, a P if on page 1 only.
  • the final difference is in the help screen that is displayed.
  • bios_equiplist and not allowed if no second diskette drive exists.
  • FIG. 40 is a flow chart describing the overall logic of the copy exercise function 48.
  • This sub-program simply makes a copy of any stored tutorial exercise in whatever disk drive directory the user specifies.
  • the program enters the copy exercise sub-program at point 60 and immediately gets the name of the exercise to copy from the user in step 1144.
  • Branch 1146 checks to see if the user has hit the escape key. If the escape key has been struck, the program automatically returns from the copy exercise sub-program through exit point 1148. If the input from step 1144 was not the escape key, branch 1150 checks to see if the input is the name for a valid
  • Step 1152 allows the user to input the desired destination drive.
  • Branch 1154 again checks to see if the escape key has been hit, and if it has, the logic automatically exits through exit point 1148.
  • Branch 1156 checks the input to see if it is a valid drive specification. If not, the logic returns to step 1152 and requests a new drive. Once a valid drive name has been input, the logic moves to step 1158 and executes the copy of the file. Once the file has been successfully copied, the program exits through point 1148 and returns to the point at which the copy exercise was called.
  • Delete Exercise begins with getting the file name and verifying it exists. It then sets a flag and requires the user to hit F6 again to verify the request. F6 sets the p_Delete_Exercise_SW switch TRUE and displays a message indicating the need to depress F6 again to delete the file. Then the system returns to await a keystroke. Anything but F6 will set the flag back to false. The F6 will set it to FALSE and then call
  • P_Delete_Exercise simply checks the name again and attempts to call remove. After successful deletion it will blank the exercise name field. It ignores the second field in this process. The return will be to page la.
  • FIG. 41 is a flow chart describing the program module delete 62 from FIG. 2.
  • This option is a simple delete file function.
  • the function first gets the name of the file to be deleted in step 1160, and branch 1164 checks to make sure that the input is a valid file name.
  • Branch 1162 and branch 1168 trap the escape keystroke and automatically exit delete 62 when the escape key is struck. If a valid file name has been entered, the program makes sure the user wants to delete the file in step 1166. When the delete order has been verified at branch 1170, the program moves to step 1172 and deletes the file. If the user decides against deleting the file at branch 1170, the program exits the delete function through exit point 1174. After a verified deletion has taken place, the program automatically exits from function delete 62. 3.
  • Rename Exercise Page 1a - F5
  • rename 64 gets the two exercise names and then calls a rename function to do the work.
  • the rename field which is the New Name field, is then switched to the exercise name field since the exercise has now been renamed, and page la is
  • FIG. 42 shows the flow chart for the rename 64 exercise function.
  • the function takes the name of any existing exercise file and replaces it with whatever new name the user desires.
  • the function gets the name of the exercise to be renamed at step 1176, checks the validity of the name at branch 1180, and renames the file at step 1182. If at any point the escape key has been struck, branch 1178 traps the key-stroke and exits the rename exercise through point 1184. Once a file has been
  • CBT7.C This no longer treats the screen as the data, but does a reasonably straight forward file read. It builds the .100 file just as in modify 46. The first file is read and written up to but not including the last record. The first record of the second file is written again to the .100 file. A From Code of 1 is put into the first record of the second file so that it forces the last valid record of the first file to be a stopping point in
  • Insert_exercise routine is called for multiple_edit
  • Insert_last_record is called to set up the proper codes in the header and used to write a proper last record at the conclusion of append_exercise.
  • append_flag variable so that the verify_action routine can know what message to place in the confirmation request - - in this case, append 66.
  • FIG. 43 contains a flow chart showing the logic of the function append file 66 from FIG. 2. This function allows the user to take two stored files and append them together to form one larger, recorded file.
  • Branch 1188 checks for the escape keystroke. If at this point the escape key has been struck, there is an exit from the append file 66 function through point 1190. If the escape key has not been struck, the input os cjecled to make sure it is a valid file name at branch 1192. If the input is a valid name, the file is opened at step 1194. If the input name is not valid, the program loops back to step 1186 and the user is asked to re-input the desired file name. Once the first file has been opened, step 1196 asks the user to input the name of the second file. Branch 1198 again checks to see if the escape key has been struck.
  • step 1200 checks the second input name. If the name is not valid the program loops back to step 1196 and asks the user to re-input the name of the second file. Once a valid second file has been named, step 1202 opens the second file. Step 1204 then opens the append output file. At step 1206 the actual append process begins by reading in the first record of the first input file. The flow chart then moves on to branch 1208. Branch 1208 checks for the end of file pointer.
  • step 1210 If not at the end of the first file, the program moves to step 1210 and writes the present record to the output file, then loops back to step 1206 and reads in the next record. The loop continues until the entire first file has been read and written to the output file.
  • step 1212 When the last record in the file has been reached in branch 1208, the program moves to step 1212 and begins to read the second file named by the user.
  • Branch 1214 checks for the last record in the second file.
  • Step 1216 writes the present record to the named output file. The program loops through step 1212, branch 1214, and step 1216, reading records in from the file and writing them to the output file, until the end of the second file is reached. At the last record, step 1218 writes out the last record to the output file.
  • Branch 1220 asks the user to accept the completed append. If the user responds negatively, step 1222 erases the output file, aborts the append process, and exits from function append 66 through point 1190. If the append is accepted, the program closes the output file and input files in step 1224 and then exits through points 1190.
  • this function is called directly from the Page 1 menu in CBT7.C, in this case by calling replace_pathway, and all operations then happen mostly in CBT18.C.
  • the process begins by opening the old file and reading it into the big buffer.
  • Get_01d_Header_Write_Exercise reads the old file and writes to the .100 file until it finds the first non-QSCR which is presumed to be the first actual pathway exercise field. At this point, the logic will skip along the .000 file without any writing until it finds another QSCR.
  • Some of the key files used by the system include the FTF file, the exercise file, the exercise directory, the defaults file, and the control files. Examples of these files now follows
  • a sample FTF file 14, suitable for recording an IRMA 3270 emulator is as follows:
  • an exercise begins with a series of recorded screens stored in an exercise file (having the extension 000). That recorded pathway will be comprised of "raw" screens - - those from which some keystroke or pointer hit is required to advance - - and "extra edit” screens which are not stopping points but are recordings of the extra screens in response to the actions taken at the raw screen.
  • One benefit of the CBT file layout and recording capability is that it allows for the recording of multiple screens with timing information in a way that allows an "expert" recording which can then be played back.
  • That simple exercise can be played back immediately on the CBT system.
  • the users must run through the modify 46 process one time (this is usually done selecting F4 off the author menu 20 and hitting the END key).
  • customizing the exercise by surrounding the pathway with instructional screens (a QSCR) and by providing more specific error messages and adding procedure lines.
  • a QSCR instructional screens
  • This may include some standard QSCR insertions to cover the objectives of the exercise and the key points to be covered.
  • the recorded exercise ends with a tag record called the "last record.” Any modified exercise must also have a last record flag in the file.
  • the system loads the exercise it will begin by filling the buffer with as much exercise as will fit. Normally the whole exercise will fit in the buffer. If an EOF is hit before a last record is found, a system error will be generated and processing will stop. That exercise will be unusable.
  • the actual file layout is based on a
  • any 80-column screen is handled in two parts, the top half and the lower half.
  • the mode that the video display is in must display the 40 as 40 and the 80 as 80.
  • an 80-column screen requires "two" screens of 40, it is normally stored in playback in ptbuff[] (the top half) and p_Low_Buff (the bottom half). When written to video memory with pokes, it is done it two stages. It is worth noting that when staging screens in playback 22, one may stop after loading pbuff[] with just the first half of an 80-column screen. That screen's header becomes
  • One identification of 40 or 80 is found in byte 10 of the header with the test: if the value of the byte & 0 ⁇ 80 equals 0 ⁇ 80 it is an 80-column screen. Another flag set when an 80 is in effect is Have_80_Column_Data_SW which is used by both CBT and recording emulator 8a.
  • flags include p_80col_SW, p_80col (set TRUE if 80), p_Cols (set as 40 or 80), and p_80col_cols which is set to 80. If the screen is 40, the TRUES become FALSE and the 80's become 40 (which means p_80col_cols is 40 also).
  • the p_Cols value is very significant because it is used in calculating where to display characters on the screen with the calculation row times p_Cols, etc.
  • the far calls need a segment and offset and new variables to get the segments.
  • routines that read and write the files are found in CBT6.C. They make calls to routines still named vbuf_fetch and vbuf_store, vbuf2_fetch and vbuf2_store. They effectively poke into the vbuf or vbuf2 arrays, using the segment and offset. The offset is the location within that array added to the actual offset location of the vbuf2 array within the segment. These fetch and store routines can be found in CBT17.C.
  • An exercise file consists of several variable length records all sharing a common format. The first three bytes are used as an identifier (though in the first record of the file they are used to provide information about the exercise used for testing and scoring purposes). The next 22 bytes provide header information that
  • variable length string comprised of the data that was on the screen, compressed using a standard algorithm, and then the attributes on the screen, also stored in
  • An 80-column screen will use three of those bytes to house the sequence to identify that the user reached the second record that makes up that screen. The first of those five bytes is used by the program for keeping track of what part of the file is currently loaded in memory.
  • Typing buffers have as their variable string a loop of five-byte components that hold the timing and location considerations along with the actual
  • Buffer length minus 1 (including Control data and Display data). Byte [1] is units (to 99). Byte [0] is 100's. This is referred to as "p_SizeMinusl”. [2] Record type (p_Record_Type).
  • [9] is column - integers.
  • the typing buffer identified as such when byte two in the header has a value of one, has the loop format beginning at byte three in the header and the remainder of the header is not used as a header but as storage for these typing blocks.
  • the block below shows the five-bytes beginning at byte three but note the second block would begin at eight, the third at 13 and so on.
  • the character is hex FF, it indicates a new field is starting due to a function key having been hit when recording from the host.
  • the typing cursor is moved to the new location but no character would be displayed for that block of five.
  • the first two bytes are very important in the loading and saving of files.
  • the read functions will read five bytes (the three that precede each header and then these two bytes), determine the number of bytes that follows in the record, and read those bytes in.
  • the first byte after that initial five will hold the record type and is significant at read time. When it has a value of three the last record has been reached and reading will cease.
  • the two size bytes are called p_SizeMinusl.
  • the next key byte is seven. With a value of 0 in this byte, a screen would be displayed but would not stop for input. The screen following would be written over it immediately. This category is primarily the
  • extra edit mode - - screens the mainframe generated in response to a keystroke or pointer hit before the next resting place.
  • a special case of this - - the mainframe's message that it recognizes a request has been initiated - - is handled by a value in byte seven of two.
  • the screen itself under that message is not saved again and this screen cannot be stopped even in modify mode.
  • a one in byte seven of the header indicates a stopping point, but not at the screen attached with the header. Rather, the stopping point is at the previous screen.
  • Default error messages are generated by the system. They can be modified by the user.
  • the main selection error message is also identified by a QSCR. It is a QSCR 2. Note that a QSCR does not have an error message but all other raw pages will have one created.
  • Typing records will also have an error message generated but these will not be a separate record. They are found in the typing record itself and are not QSCR 2 records.
  • the exercise directory is the list of available exercises that will appear throughout the system for authors and developers (students will only see the course directory described above). This list will reflect those available on the active drive (default starts at C for non-students usually).
  • the directory entries themselves are read into a structure called disp_window of which display_array is an array of 500.
  • the system uses the dos_findfirst and dos_findnext functions to build the exercise list (see CBT7.C). Each name is read into the array and using binary_insert is inserted in alphabetical order in the list as it grows and fills the display_array. When the last file is found, a filecnt variable tells how many were read in to tell where the end is.
  • the first 'page' worth is then placed on the screen on the shell that came as part of the page one screen itself.
  • the disk drive is diplayed in the shell using pdisk (the session drive indicator which can be changed and, when it is, requires the system to rebuild the directory).
  • pdisk the session drive indicator which can be changed and, when it is, requires the system to rebuild the directory.
  • Variables are kept for the Top_Of_Window which tells the number of the file now at the top (if O its first page and thus setting this 0 and redisplaying will be what Home does), and Window_Pos which gives the location of the current choice - - the highlight bar location.
  • the keys may be processed based on current values and desired effects.
  • Up Arrow, Down Arrow, Page Up, Page Down, Home, End or Enter key and the result will be reflected on the directory.
  • a function key will be reflected on the menu options.
  • a letter or number will be reflected on the exercise name field along with leftarrow, rightarrow, and backspace. (Enter off the directory also displays the name of the exercise selected automatically in the exercise field).
  • the p_Dir_Write functions build the directory for those pages, but because it also handles the directory function for the author's menu and the wildcards and differing extensions allow a directory of files other than just directories, this function builds the string for the filesearch specification. In the author menu the selected item shows up in the file name location in the lower right of the screen.
  • the function p_Dir_Display handles putting up the right entries and handling the keystrokes and redisplay.
  • the current exercise name is saved using function Psavefld before the page is officially changed to three.
  • the first default screen is then loaded and displayed using function pdispr.
  • the session drive is first. It allows the user to change the drive where the exercises are to be found and the change will be immediate. It will last until the user comes in to change it again or until the user leaves the program.
  • Another session default is the time delay for automatic playback display. Because these two blocks both require an entry and are both active at the same time, the typical menu bar (the white on red bar in the exercise directory, course directory, or QSCR4 screen) is not applicable.
  • a new display attribute (found by reading the screen itself) is used for the highlight.
  • a CBT5.C function, Prev calls the proper highlighting by giving the block parameters and the location of the one to highlight. This is called once for each block at start-up.
  • the third option is F10 again which will display the standard default screen - - the permanent one.
  • variable pdisk is updated at this point and that is the one used throughout for the disk drive in file names in the system.
  • F5-F9 will change the session time (listed in the case of this function as 5-9).
  • the F10 (translated to 0) results in a call to the standard default screen which is found and displayed with the logic returns above again to await action. It will set p_CBT_Page to five (not three now). This way, the F2 key saves the defaults back to the control loop automatically. The user is then sent back to the control loop.
  • Fields here include the permanent disk drive default, the super password used when students forget theirs, the auto_demo_time which sets the normal delay in automatic playback, light pen adjustment figures that allow the user to fine tune the light pen, and a choice of two printers.
  • F2 and ESC have any effect.
  • CBT2A.C for ESC which has as its default the resetting of the system to page one.
  • F2 is handled with the SP2KEY routine in CBT2B.C that says if the page is five call Save_Screen so these new defaults will then be made permanent.
  • Page five is really not used in the system except here. It is a catchall for future options.
  • files These are mostly compressed screens that are loaded into global variables, normally in CBT1.C.
  • the primary files are stO.pew, sto.pew, st9.pew, and default.pew (which is the copy of default?.tds that is appropriate - - i.e., s for students and x for everyone else).
  • St9.pew is the easiest and has been noted before. It is the array of error messages with a
  • the first screen (use ScrUtil - - F7 off the page one menu - - then enter file name sto.pew and +R to
  • a screen holds several variables and constitutes a file.
  • a screen is easier to look at as row, col and not linear.
  • the row and column here are the computer's row and column.
  • the ScrUtil function adds one so that row,col of 0,0 is 1,1 when the user is referring to the screen.
  • the file layout of for the course directory file is composed of the header record and then the exercise records, all of the same length.
  • the header layout is as follows:

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Technology (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Electrically Operated Instructional Devices (AREA)
PCT/US1990/003878 1989-07-03 1990-07-03 Computer operations recorder and training system WO1991000575A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US37493389A 1989-07-03 1989-07-03
US374,933 1989-07-03

Publications (1)

Publication Number Publication Date
WO1991000575A1 true WO1991000575A1 (en) 1991-01-10

Family

ID=23478802

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1990/003878 WO1991000575A1 (en) 1989-07-03 1990-07-03 Computer operations recorder and training system

Country Status (4)

Country Link
EP (1) EP0481012A1 (de)
AU (1) AU6189190A (de)
CA (1) CA2060891A1 (de)
WO (1) WO1991000575A1 (de)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5786816A (en) * 1995-10-20 1998-07-28 Araxsys, Inc. Method and apparatus for graphical user interface-based and variable result healthcare plan
US5826237A (en) * 1995-10-20 1998-10-20 Araxsys, Inc. Apparatus and method for merging medical protocols
US5850221A (en) * 1995-10-20 1998-12-15 Araxsys, Inc. Apparatus and method for a graphic user interface in a medical protocol system
US5886693A (en) * 1995-10-20 1999-03-23 Araxsys, Inc. Method and apparatus for processing data across a computer network
WO2005088453A2 (en) * 2004-03-08 2005-09-22 Computer Associates Think, Inc. System and method for continuously recording user actions and displayed images
EP2119022A2 (de) * 2007-02-09 2009-11-18 Mobile Complete, Inc. Interaktive aufzeichnung mithilfe einer virtuellen vorrichtung
WO2009102595A3 (en) * 2008-02-11 2009-12-30 Mobile Complete, Inc. Automated recording of virtual device interface

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0236747A2 (de) * 1986-03-10 1987-09-16 International Business Machines Corporation Vielseitiger Unterrichtsimulator

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0236747A2 (de) * 1986-03-10 1987-09-16 International Business Machines Corporation Vielseitiger Unterrichtsimulator

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
IBM Technical Disclosure Bulletin, Volume 16, No. 2, July 1973, IBM Corp., (Armonk, NY, US), J.F. GRANT: "Nondegrading Operating System Hooking", page 541 see the whole article *
IBM Technical Disclosure Bulletin, Volume 28, No. 10, March 1986, IBM Corp., (Armonk, NY, US) "Data Trace for IBM PC Network SNA 3270 Emulation Program", pages 4424-4425 see the whole article *
IBM Technical Disclosure Bulletin, Volume 28, No. 9, February 1986, IBM Corp., (Armonk, NY, US) "Automated Testing of Application Programs", pages 3726-3727 see the whole article *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5786816A (en) * 1995-10-20 1998-07-28 Araxsys, Inc. Method and apparatus for graphical user interface-based and variable result healthcare plan
US5826237A (en) * 1995-10-20 1998-10-20 Araxsys, Inc. Apparatus and method for merging medical protocols
US5850221A (en) * 1995-10-20 1998-12-15 Araxsys, Inc. Apparatus and method for a graphic user interface in a medical protocol system
US5886693A (en) * 1995-10-20 1999-03-23 Araxsys, Inc. Method and apparatus for processing data across a computer network
WO2005088453A2 (en) * 2004-03-08 2005-09-22 Computer Associates Think, Inc. System and method for continuously recording user actions and displayed images
WO2005088453A3 (en) * 2004-03-08 2006-06-08 Computer Ass Think Inc System and method for continuously recording user actions and displayed images
EP2119022A2 (de) * 2007-02-09 2009-11-18 Mobile Complete, Inc. Interaktive aufzeichnung mithilfe einer virtuellen vorrichtung
EP2119022A4 (de) * 2007-02-09 2010-12-01 Mobile Complete Inc Interaktive aufzeichnung mithilfe einer virtuellen vorrichtung
US8014995B2 (en) 2007-02-09 2011-09-06 Mobile Complete, Inc. Virtual device interactive recording
WO2009102595A3 (en) * 2008-02-11 2009-12-30 Mobile Complete, Inc. Automated recording of virtual device interface
EP2255350A2 (de) * 2008-02-11 2010-12-01 Mobile Complete, Inc. Automatisierte aufzeichnung einer virtuellen einrichtungsschnittstelle
EP2255350A4 (de) * 2008-02-11 2012-06-06 Mobile Complete Inc Automatisierte aufzeichnung einer virtuellen einrichtungsschnittstelle

Also Published As

Publication number Publication date
AU6189190A (en) 1991-01-17
EP0481012A1 (de) 1992-04-22
CA2060891A1 (en) 1991-01-04

Similar Documents

Publication Publication Date Title
US5317688A (en) Software agent used to provide instruction to a user for a plurality of computer applications
US4772206A (en) Multi-mode teaching simulator
US5440697A (en) Method and apparatus for simulating I/O devices
US9122601B2 (en) Advancing and rewinding a replayed program execution
US5214780A (en) Synchronized journaling system
RU2400799C2 (ru) Системы и способы обучения интерактивному взаимодействию с компьютерной программой, имеющей графический интерфейс пользователя
US4696003A (en) System for testing interactive software
US5121497A (en) Automatic generation of executable computer code which commands another program to perform a task and operator modification of the generated executable computer code
US5086393A (en) System for testing human factors and performance of a system program
Pier A retrospective on the Dorado, a high-performance personal computer
US7490031B1 (en) Mechanization of modeling, simulation, amplification, and intelligence of software
JP2001512272A (ja) コンピューター・ネットワーク上におけるコンピューター・プログラムの記憶ならびに転送を最適コントロールするためのコンピューター化したシステムおよびそれに関連する方法
US8738346B2 (en) Method and apparatus for controlling multiple simulations
US5881219A (en) Random reliability engine for testing distributed environments
KR970007760B1 (ko) 클래스 독립 파서 및 다수의 클래스 종속 파서를 갖고 있는 모듈러 컴파일러
JPH11509355A (ja) 格納された指示表現の評価によるプロセス制御
WO1991000575A1 (en) Computer operations recorder and training system
US20210299579A1 (en) Videogame telemetry data and game asset tracker for session recordings
JPH08314760A (ja) プログラム開発支援装置
EP0352908A2 (de) Computersystem und Methode, um einem Benutzer Anweisungen für eine Vielzahl von Rechneranwendungen zur Verfügung zu stellen
Cotton Languages for graphic attention-handling
Coetzee Combining reverse debugging and live programming towards visual thinking in computer programming
KR20020029918A (ko) 자동 평가 방법 및 자동 평가 시스템 및 자동 평가프로그램을 기억한 기억 매체
Crowley TkReplay: Record and Replay for Tk.
Sarma Abstracting AI Evaluation Environments with Virtual Machines

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB IT LU NL SE

WWE Wipo information: entry into national phase

Ref document number: 2060891

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1990912309

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1990912309

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1990912309

Country of ref document: EP