* Where are the FH/LUA code navigation parms

[KFN]

I'm Experimenting with PlugIns to see if I can get data out of FH7 to be useful in writing my own Report Writer.

I'm trying to find in the help text information about the navigation parms.

I've found the FH function List and some of the pointer navigation like: MoveTo, MoveNext, however some of the navigation "Data Reference" values are throwing me. (Maybe they are called "shortcuts", or not).

For example: what is the difference between NAME:GIVEN and NAME:GIVEN_ALL ? What GEDCOM data is this trying to get? Is it actually going after the NAME.GIVN tag or just the NAME tag?

I can't find a reference guide to these things in the help text in the PlugIn Tool.

Thanks

[Mark1834]

The key to resolving this is understanding how FH stores and manages names.

For example, the name of the home person in the Sample Project is recorded in the GEDCOM file simply as Ian Stephen /MUNRO/. FH neither requires nor uses the GIVN or SURN tags, although they are included for compliance.

Name qualifiers operate purely on the NAME tag, and are custom FH features. To see a list of all available qualifiers in the plugin editor, select Edit > Insert Data Reference to open the Data Reference Assistant (the same window as accessed when building a query in the main application).

These qualifiers do not have a direct GEDCOM equivalent, so can only be accessed via a function that supports qualifiers. The most common way of extracting name details is with the fhGetItemText(ptr,strDataReference) function, where ptr is an Item Pointer pointing to an Individual record and strDataReference is valid qualifier such as NAME:SURNAME.

[ColeValleyGirl]

On a more general point, the Plugin Help assumes you're familiar with topics in the FH7 Help, so it makes sense ot have both open at once.

[KFN]

Based on what you said:

Are the values in the SURN, GIVN and other PERSONAL_NAME_PIECES retained?

In the GEDCOM Specification, when used, the values in these tags have indexing and special meanings. For example, Persons with multiple given names, multiple surnames should have those names provided separated by commas.

A person with two given names such as “ Bjørn Erik”, should be entered as Bjørn, Erik n the GIVN tag, persons with two surnames, /Gonzalez López/ should be enter as, Gonzalez, López in the SURN tag.

[ColeValleyGirl]

Based on what you said:

Are the values in the SURN, GIVN and other PERSONAL_NAME_PIECES retained?

No. Names, Name Parts and Name Structures illustrates that SURNAME, GIVEN_ALL etc are extracted from the NAME field when required. Also how to access the SURN, GIVN pieces via the All tab in the property box.

[KFN]

Based on what you said:

Are the values in the SURN, GIVN and other PERSONAL_NAME_PIECES retained?

No. Names, Name Parts and Name Structures illustrates that SURNAME, GIVEN_ALL etc are extracted from the NAME field when required. Also how to access the SURN, GIVN pieces via the All tab in the property box.

So can the NAME.SURN or NAME.GIVN be used to return the actual value of those tags? These are very important in GEDCOM!

I’ll give them a try to confirm.

[ColeValleyGirl]

So can the NAME.SURN or NAME.GIVN be used to return the actual value of those tags? These are very important in GEDCOM!

Yes. But they may return different results to NAME:SURNAME and NAME:GIVEN because FH does nothing to keep the SURN and GIVN tags in step with the NAME.

[Mark1834]

Can I make a suggestion - as I said right at the beginning, FH neither uses nor requires the GIVN and SURN tags. That’s how CP designed it, and it works well in practice. A long debate on whether or not it is “correct” GEDCOM won’t change that…

[KFN]

Yes. But they may return different results to NAME:SURNAME and NAME:GIVEN because FH does nothing to keep the SURN and GIVN tags in step with the NAME.

Yes I see that now! Which for me is a good thing . The NAME:GIVEN is not the “given name” in my GEDCOM in all cases. And NAME:SURNAME returns differently than what is put in the SURN tag.

After skimming the Names and Name Parts section some of that is made clearer from a FH standpoint when all they could get in a GEDCOM in the NAME tag, I’ve pre expanded names into the Name_Parts following rules set out in GEDCOM and the customs of the individuals in the database.

I’m learning “FH Lua” navigation based on the current PlugIn code from the PlugIn library and need to interpret the navigation to fit my GEDCOM based on v5.5.1 and my move to v7.0 in the near future.

[tatewise]

FYI: The GEDCOM 5.5.1 Specification says about those name pieces:

The NPFX, GIVN, NICK, SPFX, SURN, and NSFX tags are provided optionally for systems that cannot operate effectively with less structured information. For current future compatibility, all systems must construct their names based on the <NAME_PERSONAL> structure. Those using the optional name pieces should assume that few
systems will process them, and most will not provide the name pieces.

So my interpretation is that those subsidiary name pieces are deprecated, which is why FH does not use them.

[KFN]

FYI: The GEDCOM 5.5.1 Specification says about those name pieces:

The NPFX, GIVN, NICK, SPFX, SURN, and NSFX tags are provided optionally for systems that cannot operate effectively with less structured information. For current future compatibility, all systems must construct their names based on the <NAME_PERSONAL> structure. Those using the optional name pieces should assume that few
systems will process them, and most will not provide the name pieces.

So my interpretation is that those subsidiary name pieces are deprecated, which is why FH does not use them.

No! They are still around in GEDCOM v7.0 and will be enhanced in future releases of GEDCOM. GEDCOM v5.5.1 was very “wishie washy” in those days and did not want to require things. In v7 we are still having those same discussions about requiring these tags. In actuality they will become more important over time to support various naming customs.

[KFN]

More about the above entry:

In early instances of GEDCOM only the NAME tag was present. Therefore many users of GEDCOM only provided that tag. Subsequently as the committee understood that names they were receiving were not based on Given, Middle, Surname they added the Name_Parts, but allowed for transmission to not require defined parts.

Having worked as a software developer for a very large international software company, we learned back in the 1980s that only having First and Last Names in our databases was not good in business, and I know in Genealogy it is far more important to understand the customs and not just store names!

[ADC65]

So my interpretation is that those subsidiary name pieces are deprecated, which is why FH does not use them.

When you say this Mike, do you mean FH does not use them in its internal database? Because I see the tag in the GEDCOM file:

Code: Select all

0 @I5979@ INDI
1 NAME Petan /DeLong/
2 NICK Pete

And I see it in the FH All tab:

Screenshot 2024-02-07 145821.png (10.13 KiB) Viewed 817 times

[tatewise]

Adrian, just like every other standard GEDCOM tag, FH allows them to exist.
However, FH does not actively use the GIVN or SURN tags or manage their values.
They are not displayed by default in any windows or reports (except the All tab).
It is only those two tags that were under discussion in this thread. Sorry for the confusion.
Some of the other name pieces are more actively supported by FH such as NICK.

[ADC65]

Ah, I see what you mean now, thanks for explaining Mike.

[KFN]

Adrian, just like every other standard GEDCOM tag, FH allows them to exist.
However, FH does not actively use the GIVN or SURN tags or manage their values.
They are not displayed by default in any windows or reports (except the All tab).
It is only those two tags that were under discussion in this thread. Sorry for the confusion.
Some of the other name pieces are more actively supported by FH such as NICK.

The primary reason that FH should or at least software that wants to support multi-cultural names is the need for multiple Given and Surname options.

For example: Persons that have two given names. My cousin Jon Erik. His given name is “Jon Erik” not Jon-Erik or Jon with a middle name of Erik. This is what started this thread! At first I did not realize based on Samples and active Plugins that NAME:GIVEN was not NAME.GIVN!

Persons with two or more surnames. Many cultures have two or more distinct surnames. If doing a surname study this individual would be a member of two study groups.

I realize that it is hard for software to support these name customs and GEDCOM was not designed very well to support these customs.

[tatewise]

I know it is not a global solution, but to make Jon Erik a single Given name use a no-break-space character to separate them instead of a normal space character.
Then INDI.NAME:FIRST will return Jon Erik instead of just Jon.
Also, INDI.NAME:GIVEN will usually return Jon Erik unless a Name Used (NAME._USED) value exists.

See FHUG KB How to Enter Accented and Other Special Characters that specifically mentions Double-Barrelled Names and the no-break-space character.

[Ron Melby]

To form double-barrelled names into one indivisible name, the two names can be separated by a no-break-space character code 0160, which in ƒh V6.0 can be added to the repeated space popup as follows. Click its cog, select the Hold Key (space) and click Edit, then insert Alt+0160 between any existing characters in the Accent Popup List and OK out.

when I do that, I go into the cog, place my cursor between the copyright and the next char hold down the alt, press 0 and I get a beep 1 and a beep 6 and a beep and 0 and a beep.
and no non break character is there, to select

[tatewise]

Ron, are you entering 0160 via the number keypad or using the row of digits above QWERTY on the keyboard?
Only the number keypad will work as explained in How to Enter Accented and Other Special Characters.