Family Historian User Group

It appears that the Clean Living People plugin will consider a person living if they have no birth date and no death date. This means that individuals in my tree that must have been born and died in the 1700s or 1800s get changed by the plugin. For example, if I select to change the name to Living, then these folks have their name changed.

Would it be possible (and would it make sense) to add an option to not consider individuals with no birth or death date as living? I know I can set the living flag using a query first, but it would be handy to be able to just use the plugin in some instances.

Bill

Another question on the same plugin.

If I run the plugin and I select Remove All Dates for Living Facts: and leave everything else as No Change, then I get a confirmation window that tells me to there will be 1504 items deleted and 0 items changed. I click on OK on the confirmation window. Then I click on Save on the FH toolbar.

If I then run the plugin with the same options again, it again tells me there will be 1504 items deleted and 0 items changed. Shouldn't it find 0 items to delete the second time? Is this the way it is supposed to work? Am I just confused?

Bill

Bill, I have had a quick look at Jane's Plugin.

Yes, it would be possible to add an option to ignore Individuals with no Birth Date and no Death Date.

The second problem occurs because the Plugin does NOT check for missing Date fields (or any of the other field options).
So the 1504 items are not actually deleted because they do not exist.
It is simply saying there are 1504 Facts that each might have a Date field.
So the same missing Date fields get listed the next time the Plugin is run.
This could easily be fixed.

Mike,

Thanks for taking a look at the plugin. Maybe Jane can take a look at adding the option and fixing the "problem" after the holidays sometime.

Bill

The plugin uses the EstimatedBirthDate function to get a year if no birth is found, is that not working correctly?

I don't see the problem with blank dates on my file, to save me some time can you let me have a test file with a few people in who show off the two problems and I'll try and find some time to fix it.

Jane, if there are no life dates of any sort, then the EstimatedBirthDate function returns no BirthDate, and so no BirthYear, and so BirthYear = s['LivingBirthDate'] on lines 142 to 148.
I can easily get that effect with a new unrelated Individual with no Facts.

I suggest line 148 is conditional on an option to ignore all people with no life dates of any sort, and instead sets BirthYear = 9999 .

It might improve things in some cases if the EstimatedBirthDate last parameter is increased from 3 to 9.


The other problem is caused by NULL pointers to DATE fields, in the processFact() function.
The following fixes the problem for each DATE field:
if ptrClear:IsNotNull() then table.insert(tblDeleteList,ptrClear:Clone()) end

I think SOURce links, etc, are OK.

Mike and Jane,

I'm not seeing the same results today that I did yesterday. I think I need to look at this a bit more to determine exactly what is happening and what I was doing before you spend any time trying to change things. I'm wondering if I was a bit confused as to what was happening. I'll look at it tonight and post what I find.

Bill

Mike and Jane,

OK... I've spent more time looking at this and have decided that I must have been a bit confused and my file was a little weird.

Problem 1:

As far as the first "problem" of people with no birth and death dates getting their name changed when selecting that option, the "problem" is not really as wide spread as I had thought. What made me think I had a much bigger problem than I did was that I had somehow set the living flag on for a lot of people that were not really living and could not have been living. Since I had the flag on in error, the Clean Living People plugin was correctly changing their name when I told it to. Who knows what I did in a query to get the living flag turned on for these people.

The one issue I am seeing which may or may not be a real problem is that if I use the option to force the living flag on for people with who have no death date and were born after 1910, I get a bit strange results sometimes. For example, a husband with no dates will not have his name changed, but his wife with no dates will. In this case the husband is part of my descendant "chain", but the wife has no parents.

Jane, I'll send you a small file that exhibits this "problem" so you can see if the plugin is working the way you would expect it to.

Problem 2:

This is the "problem" where I run the plugin once telling it to delete all dates for living people and it shows that x number will be delete. Then I run the plugin again, and it still says x number will be deleted. Seems like if they were deleted in the first run (which they were), then none should be there to be deleted in the second run.

Jane, again I'll send you a small file that exhibits this "problem".

Thanks to both of you for your help.

Bill

Thanks for the files.

Can you give this one a try. I have added an option to check the Spouse for dates if Estimated birth date does not return a date and also to optionally assume people whose date can not be computed are living or dead.

As per Mike's suggestion missing date fields are not counted in the items to remove and the Estimated date now searches 9 generations.

Edit:
link removed - please download from the plugin store

That is much improved Jane but there are some logical inexactitudes...

Line 152 BirthYear = BirthDate:GetYear() is much better than
the line BirthYear = fhCallBuiltInFunction('Year',BirthDate) in previous Plugin version,
because GetYear() always returns an integer.

BUT since GetYear() can never return nil, then BirthYear can never be nil, and
Line 163 if BirthYear == nil ... can never be true!
Also s['NoBirthDate'] == '1' can never be true because it is an integer not a string.
Line 163 should be if BirthYear == 0 and s['NoBirthDate'] == 1 then

Similarly, the line 153 condition or BirthYear == nil is redundant,
and the line 158 condition if not(BirthDate:IsNull()) then is also not needed.

Finally, the option Assume Living where no Birth Date is a bit misleading, because even with no Birth Event Date the EstimatedBirthDate function may give a Birth Date for the Individual or their Spouse if they have any other life Event Date such as Baptism, Christening, Marriage, Death, Burial, Cremation, or a similar date derived from any relations.
IMO a better wording would be Assume Living where no life dates.

I have made those changes if you want to check them Mike, same download link.

Looks good to me, and hopefully Bill will think likewise.

Jane and Mike,

Thanks to both of you. This version looks really good. It resolves both "problems" I was seeing.

I do have a question about the EstimatedBirthDate function. In the example file (Descendants of John Ezekiel Henshaw) that I sent to you Jane, there is one descendant line that looks like this:

John Ezekiel Henshaw
John Staley Henshaw
John Staley Henshaw Jr
James Ralph Henshaw
Jeff Allen Henshaw
Clay Allen Henshaw

Only John Ezekiel Henshaw has any dates. He was born in 1865 and died in 1922. The dates are all blank for the others.

If I run the plugin (either the old version or the new version), and tell it to force the living flag for people born after 1910 and change their names to Living, only Jeff Allen Henshaw and Clay Allen Henshaw in this line get changed.

If John Ezekiel Henshaw was born in 1865, then John Staley Henshaw would have been born no earlier than about 1885 and John Staley Henshaw Jr would have been born no earlier than about 1905 which means that James Ralph Henshaw would have been born after 1910 for sure. Also, it is very likely that even John Staley Jr was born after 1910.

Why isn't James Ralph Henshaw assumed to be living? How about John Staley Henshaw Jr? As it turns out, James Ralph Henshaw was actually born in 1947 and John Staley Henshaw Jr was born in 1924. It seems like the function isn't set to really interpret generations as well as it might be.

Thanks again for all the help.

Bill

Check what you have set in your preferences, the function uses those preferences. If you want to go the other way the function could be called with Latest rather than Earliest which will most likely mark more people as living. See the Function help in the FH Help for more detail.

Jane,

So I'm thinking you mean the preferences for Mother's age at childbirth and Father's age at childbirth.

I am using the default ranges. So if the function is called with a value of Earliest then does that mean it assumes a new generation is every 12 years? If I use Latest would it mean every 45 years since that is the maximum age for the mother?

If so, then maybe I'll try Mid which would be about 28.5 years which is closer to what an average generation is.

Thanks,

Bill

I have changed the plugin (same link) 1.2.2 now allows you to select the variant on the Estimated Date function and defaults to MID. I have also added Save Settings so that the options are remembered between runs (this will only work for gedcom files where the Version of FH is 5.0.8 or above).

Jane,

The new version works great. I really like that it now saves the settings.

Thanks for all your help,

Bill

No problem. I have updated the version in the plugin store.