Datatrieve Forms Interface (DFI) Table of Contents contents page SECTION 1 History and Functional Requirements 1.1 Introduction . . . . . . . . . . . . . . . . 1-1 1.2 Interface to Datatrieve . . . . . . . . . . . . 1-1 1.3 Screen Oriented Display and Editing of Records 1-1 1.4 Print-to-Form Capability . . . . . . . . . . . . 1-2 1.5 Field Level Protection Granularity . . . . . . . . 1-2 1.6 Easily Adapted to Changing Database Requirements 1-2 SECTION 2 USER'S GUIDE 2.1 Introduction . . . . . . . . . . . . . . . . 2-1 2.2 Restrictions . . . . . . . . . . . . . . . . 2-1 2.3 Calling DFI . . . . . . . . . . . . . . . . 2-2 2.4 Screen Manager . . . . . . . . . . . . . . . . 2-3 2.5 Field Editor . . . . . . . . . . . . . . . . 2-4 SECTION 3 PROGRAMMER'S GUIDE 3.1 Datatrieve UDK's . . . . . . . . . . . . 3-1 3.2 DFI Method of Operation . . . . . . . . . . . . 3-1 3.3 Programming DFI . . . . . . . . . . . . . . . . 3-2 3.4 Complete Syntax . . . . . . . . . . . . . . . . 3-3 3.4.1 SCREEN . . . . . . . . . . . . . . . . 3-3 3.4.2 FIELD . . . . . . . . . . . . . . . . 3-3 3.4.2.1 /NAME . . . . . . . . . . . . . . . . 3-3 3.4.2.2 /POSITION . . . . . . . . . . . . . . . . 3-4 3.4.2.3 /SIZE . . . . . . . . . . . . . . . . 3-4 3.4.2.4 /TITLE . . . . . . . . . . . . . . . . 3-4 3.4.2.5 /WRITE . . . . . . . . . . . . . . . . 3-4 3.4.2.6 /READ . . . . . . . . . . . . . . . . 3-4 3.4.2.7 /PROMPT . . . . . . . . . . . . . . . . 3-4 3.4.2.8 ! COMMENTS . . . . . . . . . . . . . . . . 3-5 3.4.2.9 /FORM . . . . . . . . . . . . . . . . 3-5 3.4.2.10 /WINDOW . . . . . . . . . . . . . . . . 3-5 3.4.2.11 /DATE . . . . . . . . . . . . . . . . 3-5 3.4.3 FORM . . . . . . . . . . . . . . . . 3-5 3.4.3.1 /GRAPHIC . . . . . . . . . . . . . . . . 3-5 3.4.3.2 /LINES . . . . . . . . . . . . . . . . 3-6 3.4.3.3 /FILE . . . . . . . . . . . . . . . . 3-6 3.5 Example . . . . . . . . . . . . . . . . 3-7 SECTION 4 BUILD INSTRUCTIONS SECTION 5 MAINTENANCE OVERVIEW DRAFT 1 (REV 3) 16 JUN 89 SECTION 1 History and Functional Requirements 1.1 INTRODUCTION In Feb, 1989, the Commanding Officer of ASDU mandated the Production Software Cell with the production of enhancements to the Software Change Request Tracking Program (SCRTP). The stated points of expansion included: - all fields of the SCR sheets be represented in the database - addition of other new fields - remove duplication of effort w.r.t. data entry - allow section level data entry for certain fields The SCR clerk, among others, was then using a program called CHANGE, which was written by Capt. Banville in late 1986 and early 1987. This program was been deemed to be unacceptable as written and generally un-maintainable. The requirements that CHANGE address were still valid, but the use of CHANGE would have to stop and a replacement found or produced. A forms product such as Forms Management System (FMS) would be able to address some of these requirements, but the cost of FMS (about $10,000) was enough to insure a wait of several months for delivery and upon delivery there would still be problems that needed to be resolved and an application developed. For less cost, greater functionality and faster availability, a similar capability was provided with custom programming by the Production Support Software staff. The following capabilities were identified as being required: 1.2 INTERFACE TO DATATRIEVE The current database must be migrated forward and all current capabilities retained. The continued use of Datatrieve provides an environment where further development and maintenance is easy and straightforward. The Datatrieve product, itself, is designed to be extensible by the user, thus providing a means to write a forms product locally. 1.3 SCREEN ORIENTED DISPLAY AND EDITING OF RECORDS Many of the fields that are to be added to SCRTP are longer than one line. Some may be up to 20 lines long. By itself, Datatrieve does not have the capability to edit the contents of such fields. The only resident capability involves re-entry of the entire thing. There is also a ceiling of 255 characters on input lines that further restricts the use of large fields. 1-1 A screen-editor approach is needed in this case. To insure user friendliness, the entire record (or selected portions of it) should be available for display/editing at a time. 1.4 PRINT-TO-FORM CAPABILITY With all the data from the SCR forms entered into the database, it would be an unnecessary duplication of effort to type this information into the boxes of pre-printed forms. The forms interface program must be able to create line & box type forms and fill them with data from the database. 1.5 FIELD LEVEL PROTECTION GRANULARITY At this time, the Datatrieve product does not have a field level protection scheme. The forms interface program must be able to provide a usable form of this capability. 1.6 EASILY ADAPTED TO CHANGING DATABASE REQUIREMENTS It is recognized that the SCRTP product is a dynamic one, with new requirements prompting new changes on an ongoing basis. The forms interface product will have to be able to quickly and easily be adapted to these changes. Furthermore, there are several other database applications within ASDU that could stand to benefit from a form type editor. It is highly recommended that the forms interface product be so designed that it may be adapted for use in any database application. N.B. The DFI/SCRTP product went into beta testing in mid-May, 1989. 1-2 SECTION 2 USER'S GUIDE 2.1 INTRODUCTION The Datatrieve Forms Interface (DFI) is a product of the ASDU Production Support Software cell and is intended to provide the members of ASDU with a screen oriented Datatrieve record editor. DFI will allow you to display and modify Datatrieve records in a simple, straightforward manner. It is designed to be easy to use and easy to create or modify applications that use it. Here is how to use it: Programmer: 1. Create your database. 2. Create a .DFI file of directives describing how to display the information on the screen and on printed forms 3. Create the table DFI_TABLE in your CDD dictionary. 4. Establish a connection between your domain and the .DFI file in this table. User: 5. Ready your database. 6. Establish a collection. 7. DFI . 8. View/edit/output as required. Steps 1 to 4 are covered in Section 3, the DFI Programmer's Guide. Steps 5 to 8 are here, in the DFI User's Guide. 2.2 RESTRICTIONS: DFI has only been tested with flat databases. Hierarchies need to be flattened (with CROSS clause) before use. 2-1 2.3 CALLING DFI At the DTR> prompt or in a procedure, DFI is called using the following conventions: DTR> DFI domain looks up "domain" in DFI_TABLE and reads the associated .DFI directive file. If this is the same file as the last time DFI was called, it uses the information already in memory. DTR> DFI assumes that you wish to use the same domain as you did on the last call. DTR> DFI domain PRINT will prepare for printed output all records in the collection. If no FORMs are defined in the .DFI directive file, then this statement will do nothing. DTR> DFI PRINT same as DFI PRINT, but assumes that you wish to use the same domain as you did on the last call. Example: DEFINE PROCEDURE EDIT READY PERSONNEL MODIFY FIND PERSONNEL WITH LAST_NAME=*."Last name " DFI PERSONNEL END_PROCEDURE DEFINE PROCEDURE SCRTP_PRINT READY SCRTP FIND SCRTP WITH SCRNUM=*."SCR number " DFI SCRTP PRINT END_PROCEDURE When DFI is called, it looks at the collection and selects the first element from it. If there is no collection or the select fails, DFI will issue the Datatrieve error message and immediately return control to Datatrieve. If the select is successful, DFI will extract its data from the fields of the record, clear the screen and draw the first screen (SCREEN 1) using that extracted data. The extracted data will be shown in highlighted (bright) video. Since many database applications are large enough that you could not fit all the fields of one record on one screen, DFI allows up to nineteen (19) screens for displaying the record. Also, since the field name is not always a clear indicator of what you want in the field, a title line appears over each field. An optional prompt may appear at the bottom of the screen as a reminder of the desired format or contents of the field. When DFI first comes up, the terminal's cursor is at the first character of the first title of the first screen. At this point you are in the Screen Manager. 2-2 2.4 SCREEN MANAGER The Screen Manager provides you with a quick and easy method of selecting the screen and field that you wish to edit. The up and down arrows will move the cursor to the next/previous title line. This is how you select a particular field. To edit that field, type the 'E' key and the field will go to reverse video, indicating that you are now in the field editor. The commands for the field editor are discussed in section 2.5. The Screen Manager provides the following functions. To activate the function, type the letter that is capitalized (no carriage return is needed). Help will display on the bottom two lines of the terminal screen the key commands for the Screen Manager. Edit enters edit mode. The selected field will change to reverse video and you may now enter or change data. Quit leaves the DFI Screen Manager and returns you to Datatrieve Redraw will re-draw the screen if something (like an operator message) messes it up on you. Select allows you to select a particular member of a collection. It is equivalent to the Datatrieve SELECT command. You type the 'S' and answer the "Select record number ? " prompt. Next is the equivalent to the Datatrieve SELECT NEXT command. -> the right arrow is equivalent to the Datatrieve SELECT NEXT command. <- the left arrow is equivalent to the Datatrieve SELECT PRIOR command. 1-9 to select a particular screen from the nine available, simply type the number of the screen. 0,1-9 for screens 10 through 19 Page will select the next screen. Msg will re-display the last Datatrieve error message received. Comment displays up to 22 comment lines from the .DFI directive file. The applications programmer can use these comment lines to give you, the user, a directory of what is in the screens. Output causes the currently selected record to be processed for forms printing. If your application does not have forms in the .DFI directive file, Output will do nothing. 2-3 Display shows you some information about what is currently on your screen. It will display Beside each title line the Datatrieve field name, current size of the contents and the wrap number (width) for the edit window. ^,v uparrow and downarrow move from field to field on a screen. moves to the next field, crossing to the next screen if necessary. Any command to the Screen Manager can be issued from the Editor by preceeding the keystroke with the GOLD (pf1) key. 2.5 FIELD EDITOR Within the screens are "windows" of bright video. When you move the cursor to the title of a window and give the Edit command, a "window" the size of the Datatrieve field is opened on the screen in reverse video. It contains the contents of the Datatrieve field. You may now edit using any of the control characters and sequences of the VMS terminal driver line editor plus a couple of extra ones. These are described in detail, below. After the line looks like what you want it to, you may save it to the database and advance to the next edit field by pressing (Carriage Return) if it is a single line or (GOLD, then Carriage Return) if is more than one line. If you wish to save the window to the database without going on to the next field, press CONTROL/Z (^Z) and the window will disappear and the contents will be saved to the database. To return to the database without any of your changes being saved, press CONTROL/C (^C). When the window is re-drawn (in bright video) it will display the actual contents of the database field. This means that the field can be verified or a date (e.g. TODAY) processed and the results shown. The supported commands are: left arrow move cursor to the left by one character, don't go past beginning of window. right arrow move cursor to the right by one character, don't go past end of window. up arrow move cursor up one line. If on first line, move to first of window. down arrow move cursor down one line. If on last line, move to end of window. If on second to last line and last line not long enough, move to end of window. backspace (^H) move to beginning of line. If already at beginning of a line, move to beginning of previous line. Do not go past beginning of window. 2-4 eol (^E) move cursor to end of text in window. linefeed (^J) delete word to left of cursor. adv. word (^W) advance cursor one word. (This is an extension to the VMS terminal driver edit set.) N.B. "WORD" is defined the same way here as in the ter- minal driver book; i.e. delimited by any control char- acter, blank or:' ,-.!"#$&()+@[\]^{|~/:;<>=? CTRL/U (^U) delete from cursor to first of window. delete delete character to left of cursor. abort (^C) (^Y) restore line's contents & exit. This is a way of abandoning all changes made to a line and returning to the Screen Manager. RETURN (^M) If the field window is only one line, exits the editor and moves to edit the next editable field. If multi- line window, it adds blanks after cursor to end of line (acts like a carriage return but does it by padding with blanks). To go to the next editable field from a multi-line window, use GOLD/ CTRL/Z (^Z) exit field editor. All changes are passed back to Datatrieve. GOLD (pf1) prepares to exit the editor. Any key struck after GOLD is returned to the screen manager, allowing you to exit the editor and perform a command simultaneously. toggle (^A) toggles between insert/overstrike modes. Default is insert, but may be changed in the source. any character inserts typed character at cursor position in either insert or overstrike mode. All characters that rotate out of the "window" will be lost upon exit (i.e. what you see is what you get) but characters are "held" in a buffer and restored if you do some deletes and the line contents shift over to make room. (Hard to describe, easy to see in example.) 2-5 SECTION 3 Programmer's Guide 3.1 DATATRIEVE UDK'S The Datatrieve Forms Interface (DFI) is implemented as a User Defined Keyword (UDK) in VAX Datatrieve. For complete information concerning the definition and use of UDKs, refer to the Datatrieve Guide to Programming and Customizing. To let you get on with the manual, I'll give you a quick overview of UDKs in Datatrieve. A UDK is implemented by writing a program that uses callable Datatrieve. The program then repeatedly gets an input line and passes it to Datatrieve, then gives Datatrieve control of everything until it reaches one of the specified stallpoints. This has the effect of looking (to the user) just like Datatrieve. To implement a UDK, the program calls the function that tells Datatrieve to look for the newly defined keyword and set the stall point mask to include the UDK stallpoint. When Datatrieve detects the new keyword, it stalls at that UDK stallpoint and returns control to the program. The program detects this stall point and then parses the rest of the line and uses callable Datatrieve to supplement its own logic to resolve the UDK. 3.2 DFI METHOD OF OPERATION Thus, the program behaves just like normal Datatrieve until it detects a UDK. At that point the custom programming takes over and retains control until the UDK's function is complete, after which control appears to return to Datatrieve. When DFI is invoked, it does the following: - all information needed to operate (less the data, itself) is stored in a directives file (filename.DFI). This includes the names of the pertinent Datatrieve fields, where to position them on the screen, how to present them in a printed form, etc. This file must be read but first it has to be identified. - DFI is invoked from within Datatrieve. Any arguments (parameters) are processed by DFI. The first parameter is nominally the "domain name". DFI will look this name up in the table DFI_TABLE (within the current dictionary) to establish the directive file desired. This table is the "glue" between a domain and its DFI directives file. It is possible to have several "sub views" of a domain by using different directive files. Each would have a different "domain name" entry in the DFI_TABLE. This is possible because DFI only deals with fields within collections; not domains. Thus, a directive file is full of field names but doesn't make any references to domains. 3-1 - The DFI directive file is read and parsed. Any errors in parsing result in an error message and a return to Datatrieve. - The most recently formed collection is known as the "visible" collection. It may or may not be named CURRENT, but this most recently formed collection is the one used by DFI. DFI will attempt to SELECT the first record in the visible collection. If an error occurs (such as there being no collection for select), DFI will display the Datatrieve error message and return to Datatrieve. - The selected record is read from the database (using callable Datatrieve) and displayed on the screen. Control is now in the Screen Manager. - The user may move about within the record or the collection using the Screen Manager. The user may also edit fields within the records. After editing each field, the Screen Manager attempts to modify that field in the database. Any errors are reported to the user. Before displaying that field again, the data is read back from the database. This allows any verification or date processing to occur and the to be displayed. - The user may request that the selected record be output to hardcopy. The forms manager will send it to an output file that will need to be manually sent to the printer upon exiting Datatrieve. - When the user leaves the Screen Manager, they are returned to Datatrieve with all collections intact. - To print an entire collection at once, the user specifies as the second parameter the key word "PRINT". 3.3 PROGRAMMING DFI The DFI directives file is like a programming language. It is read in when DFI is first called and "compiled" to control how DFI will behave. The syntax is based on the CLI parser available as part of the run time library on a VAX. Any line that is too long can be wrapped using the same convention as DCL (i.e. the last character is a minus "-" sign). The total length of all wrapped lines cannot exceed 255 characters. The display of a record can be divided up into screens, each one being a maximum of 22 lines long. Within the screen are fields, each of which is positioned on one of the 22 lines. Overlaps will be detected and treated as errors. 3-2 The printed output is divided up into forms, each one being one page or 66 lines long. A typical layout for the directive file is: SCREEN 1 ! Begin with screen 1 FIELD... ! These fields will all FIELD... ! be a part of screen 1. FIELD... ! Each is parsed as "belonging" FIELD... ! to that screen. SCREEN 2 ! Begin with screen 2 FIELD... ! These fields will FIELD... ! all be a part FIELD... ! of screen 2. FIELD... ! FORM 1 ! Define form 1 xxxxxxxxxxxxxxxxxxxxxx ! This is the text of xxxxxxxxxxxxxxxxxxxxxx ! form number 1. It will xxxxxxxxxxxxxxxxxxxxxx ! underlie the field contents. 3.4 COMPLETE SYNTAX 3.4.1 SCREEN number Valid screen numbers are 1 through 9, inclusive. Screen numbers greater than 9 are illegal and will generate an error. Screens numbers less than one (eg. 0) will indicate that all following field lines are to be input and ignored. This is handy during application development. If the number has previously appeared, subsequent fields will be added to the list of fields for that screen. 3.4.2 FIELD There is no number given to fields. They are processed on a first come, first served basis. They do NOT have to be in top to bottom order on the screen. 3.4.2.1 /NAME=field_name This establishes the connection between this part of the screen and the database. The field_name must be a field in the current collection or a Datatrieve global variable. Currently supports field names of 25 or fewer characters. This is going to change to agree with the Datatrieve conventions. 3-3 3.4.2.2 /POSITION=line This positions the field on the screen. Each field consists of a title line and the field contents window. The title line appears on the position line indicated and the field contents window begins on the next line. Since there are only 22 lines on the screen availablefor use, and each field takes up 2 lines, the maximum legal line for /POSITION is 20. 3.4.2.3 /SIZE=number This is the number of characters in the Datatrieve field. For numbers, it should be the number of digits plus signs and decimal point. For dates, a size of eleven (11) characters is needed. 3.4.2.4 /TITLE="Whatever you wish" This is the text that will appear above the field window. If not used, TITLE will default to the field name. It is suggested that if the Datatrieve field name is not very descriptive that TITLE be taken advantage of. Currently supports a maximum of 25 characters 3.4.2.5 /WRITE Will mark this field as writable. Since DFI only works on established collections, this really means to grand a MODIFY privlege to a pre-existant field. Primary keys in indexed files cannot be modified so it is suggested that /READ be used for these fields. 3.4.2.6 /READ Makes specified field read-only. Attempts to enter the editor while field with this attribute is slected will result in an information message and no further action. When DFI is searching for the next field to edit (GOLD/ downarrow from edit mode), it will skip read-only fields. 3.4.2.7 /PROMPT="Whatever you wish" When a field is selected for editing, its prompt will be displayed on the status line of the screen (line 23). This can be a reminder of what should or should not go into a field. This qualifier is optional and, if absent, the program will totally skip the screen I/O for the prompt (thus saving real time). 3-4 3.4.2.8 ! comments Any comment line that starts with an exclaimation point will be buffered in the "comment screen". This screen has a capacity for up to 22 lines. If that number of comment lines is exceeded, it will throw out all but the first 21 and the last lines read. The comment screen is available from the Screen Manager and can be used to serve as a directory of screens. 3.4.2.9 /FORM=number Indicates which form this field is to appear on for printed output. Up to 9 forms are supported. 3.4.2.10 /WINDOW=(x1,y1,x2,y2) Indicates where on the form to put the contents of the field. X1,Y1 are the coordinates (row,column) of the upper left corner of the window. X2, Y2 are the coordinates (row,column) of the lower right corner. No attempt at word wrapping will be made for field contents. 3.4.2.11 /DATE This switch controls the format of the date in the printed form. The default format is DD-MMM-YYYY. With the /DATE switch turned on, the format becomes DD MMM YY, which is the format used by the military. 3.4.3 FORM number Up to nine forms may be used. Each form consists of a "substrate" layer and a field contents layer. The substrate layer may be of VT100 graphics characters and must be 66 or less lines long. Each of the lines may be up to 100 characters long. The field contents layer is build up in a page buffer in memory out of the various windows defined in the fields for each form. Then each line of the substrate is output followed by a carriage return and no line feed followed by the corresponding line from the field contents layer page buffer. 3.4.3.1 /GRAPHIC Indicates that the VT100 graphics character set is being used. Currently this means that only LN03+ support is available. When /GRAPHICS is selected, each line of the substrate layer is preceded by (0, which turns on the graphics character set, and ended by (B, which turns it off. 3-5 3.4.3.2 /LINES=number Tells DFI that the next lines from the directives file is to be read into the substrate buffer for this form. This allows the form to be kept in the same file with the rest of the directives. The substrate buffer will only hold a maximum of 66 lines. If is larger than 66, a warning will be issued and the remainder will be read in and discarded. 3.4.3.3 /FILE=filename.ext Tells DFI to get the text for this form from the indicated file. A maximum of 66 lines is read, the rest is discarded. 3-6 3.5 EXAMPLE This is an example directives file. Please note that the lower case letters in the forms text will be converted to VT100 line graphics when output to the LN03+ printer. ! TEST1.DFI has 2 screens: ! ! screen 1 problems SCREEN 1 FIELD/NAME=PROBLEM/POSITION=3/SIZE=1000/TITLE="PROBLEM"/WRITE - /FORM=1/WINDOW=(9,2,22,79) FIELD/NAME=DATE_SUBMITTED/POSITION=17/SIZE=11/TITLE="DATE SUBMITTED" - /WRITE/FORM=1/WINDOW=(5,5,5,17) ! screen 2 solutions SCREEN 2 FIELD/NAME=SOLUTION/POSITION=3/SIZE=1000/TITLE="SOLUTION"/WRITE - /FORM=2/WINDOW=(9,2,22,79) FIELD/NAME=DATE_SOLVED/POSITION=17/SIZE=11/TITLE="DATE SOLVED"/WRITE - /FORM=2/WINDOW=(5,5,5,17) FORM 1 /GRAPHIC/LINES=24 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x AURORA SOFTWARE DEVELOPMENT UNIT x TEST1 PAGE 1 x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqvqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqu x DATE PROBLEM DETECTED x x x x x x x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqqu x PROBLEM DESCRIPTION x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ...continued 3-7 Example (continued): FORM 2 /GRAPHIC/LINES=24 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x AURORA SOFTWARE DEVELOPMENT UNIT x TEST1 PAGE 2 x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqvqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqu x DATE SOLUTION PROPOSED x x x x x x x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqqu x SOLUTION DETAILS x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 3-8 SECTION 4 Datatrieve Forms Interface (DFI) - Build Instructions The DFI product is built from the following files: DTR.FOR - main pgm. Sets up UDKs and manages normal DTR. DFI_SERVER.FOR - reads domain from DFI_TABLE and calls DFI DFI.FOR - Screen Manager. DFI_ROUTINES.FOR - reads & parses .DFI directives file etc. DFI_FORM_ROUTINES.FOR - prepares record for output EDIT_ROUTINES.FOR - field editor (Version 2.1) DMI.FOR - Menu Manager and DMI file parser DFI_COMMON.FOR - common blocks included in DFI*.for DMI_COMMON.FOR - common blocks included in DMI*.for DAB.FOR - Datatrieve Data Access Block (usually in DTR$LIBRARY, but resident in this subdirectory, anyway) DFI_SUBCOMMANDS.CLD - Command Language Definition for DFI directives DMI_SUBCOMMANDS.CLD - Command Language Definition for DMI directives DTR.OPT - linker options file The DFI product is built thus: $ FORTRAN/EXTEND DTR $ FORTRAN/EXTEND DFI_SERVER $ FORTRAN/EXTEND DFI $ FORTRAN/EXTEND DFI_ROUTINES $ FORTRAN/EXTEND DFI_FORM_ROUTINES $ FORTRAN/EXTEND EDIT_ROUTINES $ FORTRAN/EXTEND DMI $ SET COMMAND/OBJECT DFI_SUBCOMMANDS $ SET COMMAND/OBJECT DMI_SUBCOMMANDS $ LINK/EXEC=DFI.EXE DTR,DFI_SERVER,DFI,DFI_ROUTINES,DFI_FORM_ROUTINES, - EDIT_ROUTINES,DFI_SUBCOMMANDS, - DMI,DMI_SUBCOMMANDS, - DTR/OPT 4-1 SECTION 5 Datatrieve Forms Interface (DFI) - Maintenance DFI consists of four parts: a. DTR.FOR is the main program. It does relatively little except set up callable Datatrieve with the User Defined Keywords (UDKs) and spin in a tight loop of (get a line) - (let Datatrieve handle it). When it detects the DFI UDK, it will call the DFI_SERVER (in the same file) which pulls off the parameters and finds the requested filename in DFI_TABLE. It passes this to DFI (which lives in DFI.FOR) DTR SETUP DATATRIEVE SETUP UDK REPEAT GET A LINE SEND IT TO DATATRIEVE IF (UDK=DFI) CALL DFI_SERVER UNTIL (EXIT) END DFI_SERVER P1 = FIRST PARAMETER P2 = SECOND PARAMETER FILENAME = P1 VIA DFI_TABLE PROCESS P1/P2/FILENAME TO INSURE PREDICTABLE RESULTS CALL DFI (FILENAME,P1,P2) END b. Sreen Manager lives in all the DFI*.FOR programmes. Most of the communication between modules of the Screen manager is done through named common blocks. Screen Manager (NOTE: order of elements in CASE is not necessarily the order they appear in the code. Refer to the code directory on page 5 of the code) DFI IF DIRECTIVES FILE NOT ALREADY IN MEMORY THEN OPEN AND READ/PROCESS DIRECTIVES FILE ENDIF REPEAT GET DATA IF NECESSARY UPDATE SCREEN GET KEYSTROKE CASE KEYSTROKE UP_ARROW GO TO PREVIOUS FIELD (OR WRAP PAST TOP TO BOTTOM) DOWN_ARROW GO TO NEXT FIELD (OR WRAP PAST BOTTOM TO TOP) 5-1 H DISPLAY HELP LINE(S) M DISPLAY LAST DATATRIEVE MESSAGE E INVOKE EDITOR P SELECT NEXT SCREEN AND DISPLAY 1-9 SELECT THAT SCREEN AND DISPLAY D "DEBUG" DISPLAY BESIDE TITLES Q RETURN S PROMPT FOR NUMBER SELECT THAT RECORD DISPLAY R RE-DRAW DISPLAY RIGHT_ARROW SELECT NEXT DISPLAY LEFT_ARROW SELECT PRIOR DISPLAY C DISPLAY COMMENT PAGE PROMPT FOR KEYSTROKE TO CONTINUE RE-DRAW DISPLAY O PREPARE RECORD FOR OUTPUT OUTPUT RECORD END CASE UNTIL (QUIT) END c. EDITOR lives in EDIT_ROUTINES.FOR d. Callable Datatrieve. 5-2