From 6d7fe09b0eab9dd8ea3c209d59589bea6514a48c Mon Sep 17 00:00:00 2001 From: Peter Verthez Date: Sat, 12 Jan 2002 11:56:53 +0000 Subject: [PATCH] Some corrections. --- doc/interface.html | 36 +++++++++++++++++------------------- doc/usage.html | 26 ++++++++++++-------------- 2 files changed, 29 insertions(+), 33 deletions(-) diff --git a/doc/interface.html b/doc/interface.html index 74d5aad..c27e3d0 100644 --- a/doc/interface.html +++ b/doc/interface.html @@ -1,11 +1,9 @@ - - - - Libgedcom interface details +Libgedcom interface details + - - - + + +

Libgedcom interface details


@@ -1847,8 +1845,8 @@ tag.
 
The string value is the most general used value currently, for all those values that don't have a more specific meaning.  In essence, -the value that is returned by GEDCOM_STRING is always the same as the -raw_value passed to the start callback, and is thus in fact redundant.
+the value that is returned by GEDCOM_STRING(val) is always the same as the +raw_value passed to the start callback, and is thus in fact redundant.

The date value is used for all elements that return a date.  See here for the definition.
@@ -1865,7 +1863,7 @@ raw_value passed to the start callback, and is thus in fact redundant.
  Date_value_type  type;
  struct date      date1;
  struct date      date2;
-   char              phrase[MAX_PHRASE_LEN +   char             phrase[MAX_PHRASE_LEN + 1];
};
@@ -2078,8 +2076,7 @@ day number.  Two cases can be distinguished:
-
These are represented by 2 serial day numbers ( - sdn1 and sdn2) and a Date_type equal +
These are represented by 2 serial day numbers (sdn1 and sdn2) and a Date_type equal to DATE_BOUNDED.

For example, the Gregorian date "MAR 1990" is represented by the serial @@ -2124,16 +2121,17 @@ with the cross-reference, and then later extracted when the cross-reference is used or defined again in the file.  This relieves the application from the burden of maintaining the mapping between cross-references and objects.

- The parser checks whether all cross-references that are used are defined -(if not, an error is produced) and whether all cross-references that are defined -are used (if not, a warning is produced).  It also checks whether the -type of the cross-reference is the same on definition and use (if not, an -error is produced).
+ The parser checks whether all cross-references that are used are defined + (if not, an error is produced) and whether all cross-references that are +defined are used (if not, a warning is produced).  It also checks whether +the type of the cross-reference is the same on definition and use (if not, +an error is produced).  The first two checks are done at the end of +the parsing, because cross-references can be defined after their usage in +GEDCOM.

$Id$
$Name$

- - + \ No newline at end of file diff --git a/doc/usage.html b/doc/usage.html index 786cf1f..cd050df 100644 --- a/doc/usage.html +++ b/doc/usage.html @@ -1,9 +1,7 @@ Using the GEDCOM parser library - - - +

Using the GEDCOM parser library


@@ -94,8 +92,7 @@ actual callback mechanism, although it also uses a callback...
result = gedcom_parse_file("myfamily.ged");
In the above piece of code, my_message_handler is the callback - that will be called for errors (type=ERROR), warnings ( - type=WARNING) and messages (type=MESSAGE).  The + that will be called for errors (type=ERROR), warnings (type=WARNING) and messages (type=MESSAGE).  The callback must have the signature as in the example.  For errors, the msg passed to the callback will have the format:
@@ -169,7 +166,7 @@ a GEDCOM file.  First, have a look at the following piece of code:

void my_header_end_cb (Gedcom_ctxt self)
{
-   printf("The header ends, context is %d\n", self);   /* context +   printf("The header ends, context is %d\n", (int)self);   /* context will print as "1" */
}

@@ -207,7 +204,7 @@ need to have the signatures as shown in the example.
gedcom.h (so no need to include gedcom-tags.h yourself).

The example passes a simple integer as context, but an application could - e.g. pass a struct that will contain the information for the + e.g. pass a struct (or an object in a C++ application) that will contain the information for the header.  In the end callback, the application could then e.g. do some finalizing operations on the struct to put it in its database.

@@ -263,11 +260,11 @@ for this)
The subscription mechanism for elements is similar, only the signatures of the callbacks differ.  The signature for the start callback shows - that the context of the parent line (e.g. the struct that + that the context of the parent line (here e.g. the struct that describes the header) is passed to this start callback.  The callback -itself returns here the same context, but this can be its own context object +itself returns here in this example the same context, but this can be its own context object of course.  The end callback is called with both the context of the -parent and the context of itself, which will be the same in the example. +parent and the context of itself, which in this example will be the same.  Again, the list of identifiers to use as a first argument for the subscription function are detailed in the interface details .
@@ -278,7 +275,7 @@ level number (the initial number of the line in the GEDCOM file), the tag raw value is just the raw string that occurs as value on the line next to the tag (in UTF-8 encoding).  The parsed value is the meaningful value that is parsed from that raw string.  The parsed tag is described in - the section for record callbacks.
+ the section for record callbacks above.

The Gedcom_val type is meant to be an opaque type.  The only thing that needs to be known about it is that it can contain specific @@ -291,9 +288,8 @@ level number (the initial number of the line in the GEDCOM file), the tag @@ -361,6 +357,8 @@ specifically subscribed upon by the application, and can thus be called in various contexts.  For simplicity, the example above doesn't take this into account (the parent could be of different types, depending on the context).
+
+Note also that the default callback is not called when the parent context is NULL.  This is e.g. the case if none of the "upper" tags has been subscribed upon.
-- 2.30.2