GEDView 1.10 - Beta test release - 4 July 1994 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ USAGE: GV GEDCOM is a popular genealogical data format. It was developed by the LDS Church as a way to exchange data between two systems -- whether those systems be two computers connected via a modem or two genealogical programs utilizing different database schemes. GEDCOM is so widely available that most programs of any merit will import and export in the GEDCOM format. GEDView will interpret and display that data. It is not, however, a program that one can use to create a genealogical data base. It is essentially only a reader. GEDCOM files have become very accessible, particularly to the "online" community. However, not everyone owns or uses a GEDCOM compatible program. Although GEDCOM files are written essentially in the standard ASCII text format, they can be fairly difficult to browse through. GEDView organizes each record into a highly readable form. Related records can be easily accessed by tabbing to or clicking on a GEDCOM "pointer." (A pointer is essentially a label for another record.) Tag names, or field names, are translated into more description words or phrases. Tag names that are not described by GEDCOM draft 5.3, are displayed in caps, preceded by an asterisk (*). Any displayed record can be saved to a file. Additional records can be appended to the same file. It is possible, in fact, to create a new file by selecting records from the original GEDCOM file. The "enhanced" display can be converted back to a standard GEDCOM record by pressing F8. Records can then be saved to a new file in regular GEDCOM format, allowing for the creation of a new GEDCOM file. There was no attempt to create sophisticated genealogical charts with this version. I have, however, given GEDView the capability to utilize user-written scripts -- or programs. Although the command set at present is very limited, tasks can be very easily customized and automated with this feature. Some examples are included and described below. My intent for future versions is to further improve the "engine" - making it even faster and more efficient, and to extend the script command set, making it possible for virtually any task to be automated. Indeed, unlike other programming projects, I can envision the day when GEDView will actually be finished - a fast, lean and highly configurable GEDCOM processor. SPECIFICATIONS ~~~~~~~~~~~~~~ I used the specifications for the proposed GEDCOM standard, draft release 5.3. All tags described in that document are supported by GEDView. GEDCOM is a highly flexible format, making it fairly easy for a developer to readily export data into a GEDCOM compatible file -- and visa-versa. However, this flexibility also causes problems. I have found at least two "GEDCOM" files that I can only describe as unreasonable. -- All data is organized into one record -- the header record, which is generally used only to record basic file information, such as the file name, the compiler's name and the name of the software that generated it. GEDView will not work on such files -- and I am not too upset about it. GEDView is designed to handle with a file size of up to 2 gigabytes and will read as many records as can be squeezed into that. Each record can be up 32,000 bytes in length. Up to 8,000 lines can be included in a script. GEDView was written to be fast. It will index, or create look-up tables, for a GEDCOM file at the rate of about 10 seconds per megabyte and will do a global search in about 8 seconds per each megabyte (as performed by on my 386DX-33). GEDView supports color and a MicroSoft mouse. Commands can be entered via pull-down menus, mouse buttons, textual commands and scripts. GEDView will create several new files for *each* GEDCOM file that is read -- and they are not deleted when the program ends (the -n switch can be used on the command line to suppress the indexing of an already indexed file.) Be sure there is plenty room on your disk. The amount of space that GEDView requires can probably be determined by the number of records in the original file. I have not yet done the arithmetic. BUGS ~~~~ At this writing, I am aware of two bugs. First, on a CGA monitor, the cursor disappears in overwrite mode (insert, a full block, is the default). Although only one GEDCOM file can be opened at any one time, several files can be opened in succession. However, at least on my system, GEDView fails on the 10th file. -- Apparently, it has run out of memory. This is probably the result of a small piece of allocated memory that I have not freed before each load -- causing an accumulation and eventual exhaustion of the systems memory. It's there, and is easily fixed - I just haven't found it yet. I have learned that SpeedStar video cards are not compatible with some applications written in MicroSoft C. That has been true with at least two of my programs. I understand, however, that there is a fix for that problem. WRITING SCRIPTS ~~~~~~~~~~~~~~~ I have a text editor in the works and will make it available in a future release. In the meantime, GEDView scripts can be written using any editor or word processor - SAVED AS AN ASCII FILE. GEDView does very little syntax error checking. And I have done little to discover the results of bad code. The best advice I can give right now is to be careful. The script commands are found in the Help menu. * Always conclude your script with an END statement. * The resulting of an IF statement must go on the next line. * Do not call a script from within another. * Do not include blank lines in your script. Below is a sample script I call SEARCH.PRG. To invoke it, type RUN SEARCH.PRG at the dot prompt or select Run Script from the Reports Menu. SEARCH.PRG looks for the word Mayor. If it finds it, it displays the record and pauses. If you do not want the record printed to TEMP.GED, press the escape key; otherwise, press any other key. Once the end of the file has been reached, the script returns you to the record you started with, saved in the $RECORD variable. I have "commented out" the SET DISPLAY statements by placing an asterisk in front of them. (Comments and otherwise blanks lines can be added freely in this way without hindering the program. Lines can also have any number of spaces or tabs in front of them.) To have the script automatically create the new file -- without hardly a notice on your part -- remove the asterisks and the IF ESCAPE commands. If a GEDView command is not successful, the FAILED flag is set. -- An IF FAILED will check the status of the command IMMEDIATELY preceding it. Therefore, nothing, not even a GOTO or a label can come between the two line (the command to be checked and the IF FAILED). If your program is recursive -- that is, returns to the top over and over -- You must check for a failed condition to end the execution. Otherwise, you will stuck in an "infinite loop" and will probably have to reboot your system. -------------------------- *set display off set format off remember $record go 1 save temp.ged "0 HEAD" append temp.ged "1 SOUR GEDVIEW 1.1" find global Mayor if failed goto the_end pause if escape goto skip_that :continue append temp.ged :skip_that find next if failed goto the_end pause if escape goto skip_that goto continue :the_end append temp.ged "0 TRLR" set format on *set display on go $record end There are 3 additional scripts included: FATHER.PRG, MOTHER.PRG, and FLINE.PRG. The first two cause the program to jump to the respective parent. FLINE.PRG is essentially a recursive FATHER.PRG. It ends when the last record of the paternal line is displayed. The command set right now is very primitive and will not do a lot. I would, however, be very interested in seeing any script that you might come up with. Please, please report any and all bugs to me. There are undoubtedly several there that have not shown up on my system. And feel free to try to "break" GEDView. I would be very interested in the results. Please contact me, preferably through email, concerning any questions or comments. I will be out of town between July 5 and July 15 but will respond to your message after I return. Michael Cooley 4 July 1994 P.O. Box 593 Santa Cruz, CA 95061-0593 email: michael@emcee.com nqf@netcom.com mikecooley@aol.com