#2812 Editing single line shared note not working

v4.2.3
open
nobody
None
5
2010-05-23
2010-05-23
Phil
No

Editing a single line shared note, and leaving it as a single line fails on save with "ERROR 20: Invalid GEDCOM format"

The culprit is the same code I pointed to for the previous bug report on editing shared notes: edit_interface.php:1389
if ($k==0 && count($newlines)>1) {
$gedlines[$k] = "0 @$pid@ NOTE $newlines[$k]\n";
} else {
$gedlines[$k] = " 1 CONT $newlines[$k]\n";
}
If the note is a single line [count($newlines)==1], then it gets stored as a CONT record instead of a NOTE record. Looks like that if should be:
if ($k==0) {
I have no idea what that count check is attempting to do.

Here is some quick code to handle this and the problem with line count changes: WARNING: I *AM* a programmer, but PHP is not a language I have used much. This worked on my simple tests for the previous failing cases, but I am not setup to do any sort of regression testing. Lets see how badly this formats pasted in here: edit_interface.php:1388
remove:
for ($k=0; $k<count($newlines); $k++) {
if ($k==0 && count($newlines)>1) {
$gedlines[$k] = "0 @$pid@ NOTE $newlines[$k]\n";
} else {
$gedlines[$k] = " 1 CONT $newlines[$k]\n";
}
}
add:
$tmplines = array();
//Build new raw note [no CHAN]
for ($k=0; $k<count($newlines); $k++) {
if ($k==0) {
$tmplines[] = "0 @$pid@ NOTE $newlines[$k]\n";
} else {
$tmplines[] = "1 CONT $newlines[$k]\n";
}
}
// Find end of previous raw note
$tmplastline = 1; // in case the note is a single line: the *first* line 'better' be a NOTE line
for ($k=1; $k<count($gedlines); $k++) {
$tmplvltag = substr( ltrim( $gedlines[$k] ), 0, 7 );
// Regex \^1 CON[CT] \ if ($tmplvltag !== '1 CONT ' && $tmplvltag !== '1 CONC ') {
$tmplastline = $k;
break;
}
}
array_splice( $gedlines, 0, $tmplastline, $tmplines );
unset($tmplines,$tmplvltag,$tmplastline);

This does not yet handle CONT versus CONC, and it will generate invalid data if a blank line is supplied as part of the note. So did the original code, but was not as obvious. With this code, a blank line at the end of the note creates a "1 CONT" record with no delimiter and no data. That is invalid according to the GEDCOM spec, unless the line has sub lines. That is bad enough, but the code I used includes the delimiter in the check for the end of the CONT and CONC lines. That means that the next edit for the note will keep the invalid blank line, even if it was deleted during the edit. Sigh. The test for a non CONC/CONT line needs to be smarter. Maybe a regex like \^1 CON[CT]( |$)\

That does point out another general issue though. From what I see, the code saving GEDCOM lines does trim() on the line before saving. I did not see anything in the GEDCOM specification that said that white space at the end of lines was invalid, at least in contexts where no delimiter is expected. A line like "1 CONT " (2 spaces after CONT) should be a valid alternative to the "1 CONT" being generated in some cases now.

Discussion

  • Phil
    Phil
    2010-05-23

    • summary: Editing single line shared not not working --> Editing single line shared note not working
     
  • Phil
    Phil
    2010-05-23

    Simple [temporary] fix so that the invalid blank records to not get kept. Still can be generated, but they can be removed again with another normal edit.
    After:
    $tmplvltag = substr( ltrim( $gedlines[$k] ), 0, 7 );
    Add:
    if (strlen($tmplvltag) == 6 ) { $tmplvltag = $tmplvltag.' '; }

     
  • Stephen Arnold
    Stephen Arnold
    2010-05-23

    I don't see this problem. Just added a one line shared not to this record, using the OCCU tag.
    http://www.myarnolds.com/individual.php?pid=I2017&ged=Arnold.ged

    Please review and advise why you think there is a problem. The SN code was devised to show the first line as the TITL.
    Stephen

     
  • Stephen Arnold
    Stephen Arnold
    2010-05-23

    OK, I guess I do see your error when using the GUI. If I raw edit and remove the 1 CONT line, it works correctly, but the GUI will not remove the line that was added as part of the creation of the SN. More to the point, we need to look at the creation process and see if we can determine why the extra 1 CONT is added following the one line.
    Stephen