PhpGedView

Logged In: YES
user_id=1337066

Oops. Ok. I expempted forced sort for BIRT when the sort
check is BIRT vs BIRT. So, it should behave as before for
sorting children.

The actual result was insert each new child at the top of
the list, so it was producing a list in reverse order of
being added to the family.

Logged In: YES
user_id=1061833

Not sure if your work precipitated a new bug or if it was
something else, but from:

FAM > EDIT > REORDER Children

Children reorder in last as first order rather than oldest
to newest as was the case before. FYI
Stephen

Logged In: YES
user_id=1337066

Ok. I have forced some sorting and checked it into future CVS.

1) BIRT is first. Even if dates recorded are exact and
disagree, BIRT will come first. It is overly heavy handed
and simplified, but it works.

2) CREM follows DEAT. Again, even if the dates disagree,
CREM will follow DEAT.

3) BURI follows CREM and DEAT. Again, even if the dates
disagree, it will follow DEAT.

4) If DEAT/CREM/BURI was undated, such as DATE = "UNKNOWN",
or "Y", or did not exist in the record, they sink to the
bottom of the sort list. This kills the case of DEAT DATE
Y, floating in the middle, and being followed by CENS.

5) CHAN is always last. Same as it always been.

6) If DEAT has a date, then other records like WILL with a
later date can follow it.

Logged In: YES
user_id=1337066

Ok. I will go after it this weekend. I have an unchecked
in code snippet for making sure BURI and CREM come after
DEAT and they all fall to the bottom, especially if dated
with UNKNOWN or Y. I will add making sure BIRT comes first
and get in checked in.

Logged In: YES
user_id=1061833

Still have the same sorting issue on BURI. It should always
follow DEAT (unless you are particularly sadistic), yet if
BURI date is the general year and DEAT is specific, then
BURI preceeds DEAT, and even BIRT. PGV sorted the following
for display:

BURI 1999
BIRT 02 MAY 1999
DEAT 03 MAY 1999

as BURI > BIRT > DEAT.
This is obviously incorrect. I know there was a previous
discussion on sorting, but BURI should always be one of the
last EVENTs (although not necessary forced to be the very
last as other events can follow BURI.
-Stephen

Logged In: YES
user_id=1339926

yes, i'm sure that birth is first! ;-)

PGV should know that the first event is BIRT (except some
prenatal events) and the last is BURI. if it recognices
that there is a logical conflict because of the provided
dates it should post a warning - with the reason for this
conflict. i have a lot sources which partly conflict to
each other, you won't find all conflicts if you are not
supported by a machine.

Of course it is possible to provide the date information as
you supposed with an AFT like

1 CHR
2 DATE AFT 02 FEB 1999

_BUT_ that could not be the solution as

1. the provided information is incorrect in case that BURT,
CHR and DEAT fall on the same day! after 2 is 3 and not 2!

2. you can't expect that every user provides the
information in the correct manner. Most of my users don't
realize at all that they could provide AFT, BEF, ABT
(more?) with datefields. Perhaps they would type 'nach
1945' or something like that. i suppose that most of the
non-english speaking people have similar problems.

3. typically you hear 'birth was about 1907 and christening
same year or one year later'. in these cases PGV should
display BIRT first and than CHR regardless of their phys.
position in GEDCOM.

btw, 3.3.8 and 4.0b7 worked as expected - at least for this
point.

Christian

Logged In: YES
user_id=1466942

1999 is assumed to be 01-jan-1999.

If you are certain that the christening came after the birth
(!), then perhaps you could enter

1 BIRT
2 DATE 02 FEB 1999
1 CHR
2 DATE AFT 02 FEB 1999

Suppose you had entered this (because you have conflicting
sources of data)

1 BIRT
2 DATE 02 FEB 1999
1 CHR
2 DATE 07 JAN 1999

What should PGV do here? Sort the data as you explicitly
specify it, or ignore you and reorder it. I think using the
AFT qualifier is the best approach.