Family Historian User Group

I downloaded the just release v4.3. I first renamed the v4.2 plugin by putting '-V4.2' in its name, then inserted v4.3 in the fh_lua folder. The settings appear to have been preserved from 4.2 so ran the plugin. Then next loaded the renamed V4.2 plugin, but found that many of the settings had changed. I think renaming the plugin caused it to lose custom settings and reset to default settings because it couldn't find a .dat file.

Are plugin options stored in :\Family Historian Projects\FHkmtrees\FHkmtrees.fh_data\Plugin Data\? I suspect so, and also that, for updated plugins, as long as plugin name is exactly the same, it will always pickup the old plugin's settings from the .dat file. But I wish to keep the old plugin around for awhile, with the right settings. How do I best do that? Rename the .dat file at the same time as the plugin file? That would seem to be logical.

That said, the V4.3 plugin output appears to compare favorably to V4.2. Comparing to a recent 4.2 gedcom, the only differences I detected was some '&amp' changed to '&' in text, as well as some styling was removed.

Ron

Something unusual is going with registering FH V7 plugin names that I am investigating now...

That trick of renaming Plugins is one I use all the time to keep old versions available but using the same Plugin Data settings.
It only works in my Plugins, but something is preventing it here.

OK, I never use dot . in my Plugin names and if you use dot . it confuses FH V7 into registering a new Plugin name.
( I don't think FH V6 had that problem. )

So use any symbols except dot . in names, e.g. Export Gedcom File-V4-2 or Export Gedcom File + V4:2

OK Mike,

Thanks will no longer use the dot in the rename and see how that goes. You say only your plugins, so I take it only your plugins are written to ignore the version portion in the name (up to the dot) and thus load the proper prior plugin .dat settings. So with this procedure I need not rename any .dat files?

I ran a test, renaming the 4.2 plugin without the 'dot'. It still didn't find the old settings that v4.3 does and reset the settings.

I should mention, to distinguish installed FH7 released plugins from those still from FH6, I uppercase the first word of the name. This has worked fine since the plugin Check Installed Plugins Against Store does a case insensitive comparison. This keeps me from accidentally running an FH6 plugin, but still alerts me if there is a new release of the plugin.
I don't think this is causing the settings issue, since EXPORT Gedcom File plugin finds the Export Gedcom File.dat old custom settings file OK.

Hope this makes sense.

Ron

What my Plugins do is compare the Plugin Title shown at the bottom of the Tools > Plugins... window against the Plugin Name in the pane above, and strips away the suffix that does not match. That resulting name is used to access the Plugin Data file.

It is case sensitive, so capitalizing the first word will upset that matching process and use a different Plugin Data file.
It will also fail my internal consistency checks and raise a warning message.

My names all use the following format Export Gedcom File - Vj-k and have worked fine for years.

OK, thanks for clarifying. I neglected to mention the consistency error '@title' mismatch I was getting. I will rethink my approach. Thanks for the clarification. However, I will note that the uppercased name 4.3 version still found the proper .dat settings, because I compared with what I had in my full project backup.

My first post in two years! Using the latest 'Export Gedcom File' with unchanged export parameters and noticed something has changed. Before, creating a fact of 'death' without any date would cause a DEAT 'Y' record to be exported. Now I see that the DEAT record is blank. This is causing TNG to assume the person is Living.

However, not all are handled this way; only new persons I have entered recently that have no death date. The 'death' fact looks the same those with and without the DEAT 'Y'. Both show a sentence 'She (or He) has died.

So not sure this is a plugin issue, but something in data entry.

Thanks for any help.

Ron

Are the new person Death events so new that you have not closed and reopened FH?
FH only adds the Y after a close and reopen sequence.
I reported this to CP in 2016 but it still has not been fixed!

Hi Tatewise!

Way back when, did testing with you on the TNG import requirements and it has worked very well for me. It is evident this is an issue in FH, not your plugin.

Yes, I have opened and closed (and saved) sessions in FH many times. Can I fix this with a Search and Replace somehow?
However, those with death dates, will also have a DEAT gedcom record without a 'Y', won't they, and having that on those perhaps would be a problem?

Thanks for the quick reply.

Ron

Ron, can you please clarify what you are seeing?
If any event such as Death has no Date and no Place then it should have Y after the DEAT tag in the GEDCOM.

Are you sure you are seeing DEAT with no Y and no DATE and no PLAC tags?

Please post a snippet of GEDCOM that exhibits those characteristics after closing and reopening FH.

You are correct that it is NOT a plugin issue, which simply passes that GEDCOM structure through to the exported GEDCOM.

An example:
0 @I15355@ INDI
1 NAME ludmilla //
1 SEX F
1 DEAT
1 FAMS @F5104@

More examples from gedcom

1 FAMC @F4787@
0 @I15348@ INDI
1 NAME Ulric /Urban/
1 SEX M
1 DEAT
1 FAMS @F5469@
0 @I15349@ INDI
1 NAME Andrea /Schwartz/
1 SEX M
1 DEAT
1 FAMS @F5470@
0 @I15350@ INDI
1 NAME Ursula //
1 SEX F
1 DEAT
1 FAMS @F5470@
0 @I15351@ INDI
1 NAME George /Kleiner/
1 SEX M
1 DEAT
1 FAMS @F5471@
0 @I15352@ INDI
1 NAME Adam /Millberger/
1 SEX M
1 DEAT
1 FAMS @F5472@

However, I have older entries that have no PLAC, DATE but do have DEAT Y

0 @I15079@ INDI
1 NAME Johann /Vlasak/
2 SOUR @S77@
1 SEX M
1 DEAT Y
1 FAMS @F5382@

Does merely have SOUR cause a 'Y' perhaps?

Ron

Ron, I have just inserted that snippet into FH, then opened, save, closed, opened, and saved again.
FH automatically added the Y after DEAT.

The problem of the missing Y arises in situations where there are empty DATE or PLACe tags, such as when a fact is initially added, or those two fields have their values deleted but not their tags. Then when FH closes the empty tags are purged but the Y is not added. So FH must be closed and opened again to add the Y.

Are you checking the FH Project GEDCOM file? It won't propagate to the exported GEDCOM until you rerun the plugin.

I am fascinated that none of those Individual records has a 1 CHAN updated date/time stamp.
How were they created?

These folks were added in several sessions several days ago.

I always saved before exiting FH, and had reopended FH several times after that. And have exported several times as well.

I will be out for an hour or so.


Ron

What I don't understand is the lack of change timestamps such as:

0 @I15348@ INDI
1 NAME Ulric /Urban/
1 SEX M
1 DEAT
1 FAMS @F5469@
1 CHAN
2 DATE 16 MAR 2023
3 TIME 16:58:44

Please confirm that you are checking the Project GEDCOM file in the .fh_data folder.

Again I have pasted your longer snippet into a GEDCOM and opened, saved and closed FH and it adds the Y after DEAT.

I have stepped through the process of adding an Individual, setting their Sex and adding a Death event.
Initially, that record is saved without Y on DEATH but with a 1 CHAN date/time stamp.
Opening, saving and closing FH a coupled of times added the Y to DEAT.

0 @I15079@ INDI
1 NAME Johann /Vlasak/
2 SOUR @S77@
1 SEX M
1 DEAT Y
1 FAMS @F5382@

Does merely have SOUR cause a 'Y' perhaps?

GEDCOM has this statement about DEAT tag:

All GEDCOM lines have either a value or a pointer unless the line contains subordinate
GEDCOM lines. In other words the presence of a level number and a tag alone should not be
used to assert data (i.e. 1 DEAT Y should be used to imply a death known to have happened but
date and place are unknown, not 1 DEAT ).

Mike,

Sorry, I thought I had noted it, but obviously I didn't, that my snippets were from the exported file, not FH's data file. Indeed the DEAT Y is in the fh_data file, but it is was not carried forward to the exported file from that first time running the plugin. I was certain I 'saved' the file before running the plugin on my last batch of entering death events without date or place, but it's possible I hadn't exited FH and reloaded.

Anyway, I closed and reopened again, ran the plugin, and this time the DEAT Y carried over to the export file fine. Sorry to have bothered you with this one.

Ron

I have similarly just run the Export Gedcom File V5.4 plugin and it exports the 1 DEAT Y line perfectly.
The 1 CHAN timestamp would only be excluded if you have set the Extra Options tab, Updated 1 CHAN setting to Remove entirely which is not a default TNG setting.

I cannot think of anything that causes the plugin to remove the Y from the DEAT tag.
Are you sure you have run the plugin after 07:14 today?
That is the datetime stamp on those snippets you posted, so running the plugin on an earlier date may have been when the Y is missing from DEAT because FH has not been opened, saved and closed enough times.

As I explained earlier, just saving FH after entering new Individuals with blank Death events is not enough.
FH must be closed, saved and opened enough times to purge the empty DATE and PLAC tags and then add the Y.
You could raise the problem with CP which they have ignored for 7 years.

Mike,

Sorry if my last answer was too cryptic. Bottom line is all is OK. I had recently put in the 'died' event for 40 or so individuals, and apparently exported after saving, but didn't exit and reopen FH.

Thanks for explaining how this happened. Usually 'saving' your work is sufficient, but in this case that is not enough. Is this true with many other data fields as well? I will raise the issue with Calico Pie as you suggest.

Regards,

Ron

The only other cases are where the user deletes the contents of field but the empty tag is not deleted until FH is closed.
However, the consequence is simply that an empty tag might get exported which usually does no harm.
It is the combination of that effect with a new Event and the need to add Y if there is no subsidiary data that causes a problem.
i.e. when reporting the issue to CP don't restrict it to just Death events as it also affects Birth and Christening events.