* Updating age by plug-in

[Mark1834]

FTM has no specific field for recording ages in event entries, so I have a huge number of ages recorded as NOTEs that I wish to convert to "proper" ages within FH. The format is very consistent, either just "age xxx" or "other comment, age xxx", so a plug-in is the obvious way to go.

I have code that does what I need, but the problem comes when the age is not a valid GEDCOM age (e.g. "5½", "6 weeks", etc.). When the age is set with fhSetValueAsText(ptAge, strAge), FH does the same type of "adjusting" as when similar text is entered directly into the Property Box, so the examples above become "5y" and "6y", respectively. This behaviour is fine when you can see the result directly, but totally unacceptable when it is happening blindly, as when a plug-in is running.

There is no difference in the return value of the fhSetValueAsText() function, as this is a general function and the argument presented is valid text, but neither is it returning any internal flag within the program to say that the text has been modified.

At the moment, my pattern matching to extract the age is relatively unconstrained (strAge = string.match(strNote, "^age (.+)$") and strNewNote, strAge = string.match(strNote, "^(.+), age (.+)$") for the two alternative forms given above). My first thought is to modify the pattern matching so it only takes valid GEDCOM ages (conservatively, an integer optionally followed by a single 'y', 'm', or 'd'), but this feels a little like a workaround. Is there a way of alerting the user to the fact that FH is making assumptions and changing data, or is it down to the plug-in writer ensure that only clean and valid data are presented to the program?

[tatewise]

I've moved this to the Plugin Discussions Forum.

Essentially, it is down to the Plugin author to ensure all data transactions are valid.

You can use fhGetValueAsText(...) to read the Age back and compare with original text.
The valid values are:
1 dy
99 dys
1 mn
99 mns
1 yr
99 yrs
or any valid combination of those such as
1 yr 2 mns 9 dys

Having captured the strAge text, I suggest you use patterns for all the variants and valid translations.
e.g.
strNew = strAge:gsub( "^1$", "1 yr" )
strNew = strAge:gsub( "^(%d+)$", "%1 yrs" )
strNew = strAge:gsub( "^(%d+)½$", "%1 yrs 6 mns" )

The way I handle that is to create a table of pairs of gsub parameters and loop down the table until strNew ~= strtAge.
The order of entries is important, e.g, "^1$", "1 yr" must precede "^(%d+)$", "%1 yrs" otherwise you will get 1 yrs.

After using fhSetValueAsText(...) then use fhGetValueAsText(...) and compare.
If any difference detected then report, perhaps in a Result Set.

[Mark1834]

Thanks Mike, useful message that responsibility lies with the author....

This script will only be used a couple of times (once on each of my main FH projects) and the ages are generally recorded as either simple integers for years, or with 'd', 'w' or 'm' suffix as appropriate , so I think the method that will work best is to extract the age using my existing free format expressions, then test the value against simple templates with the additional line

strTest = string.match(strAge, "^(%d+%s*[ymd]*)$")

If strTest and strAge don't match, I present the problem string to the user with iup.GetText and invite a correction. These lines will be in a loop that repeats until a valid format is entered or the user presses <Cancel> to indicate "don't process this record". Odd-ball cases such as fractional years can be processed manually afterwards, as there will only be a handful at most.

It's too late to work the detail tonight, but that's a job for tomorrow...

[Mark1834]

Sorted - the following code fragment worked well on a test copy of my main FH database. It found about a dozen records where I had abbreviated "months" as "mo" or written out in full, and about half that number where the age was followed by other text (e.g., "age 59, Disabled"). Had there been more it might have been worth investigating writing to a table for easy reference afterwards, but this is fine for present purposes.

Now to do the same for Death, Burial and whatever else FTM doesn't record ages for...!

Capture.PNG (10.36 KiB) Viewed 3235 times