

         GEDView 1.10 - Beta test release - 4 July 1994
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

         USAGE: GV <filename>

         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 <action> 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
