* Error when Running "Change Specific Fact Tab"

[MFriend]

Hi Folks:
I am trying to use the "Change Specific Fact Tag" plugin. I believe it will let me change some of my residence facts to census facts.

Anyways the tree I'm running it on was a direct import from Rootsmagic 8. I get the following two errors:



Thanks,
Matthew

[Valkrider]

Looks to me like your file path is too long. Don't forget the 255 character limit.

[Mark1834]

I think that comes in under 255. More likely, it is an issue with how custom facts are imported from RM. I'll have a play over the weekend to identify what the issue is...

[MFriend]

Mark:
Just to make sure it was not a file path issue, I moved the project to my (internal) D drive root and shortened the folder names. The error is still the same. Just in case it might help you, I zipped and uploaded the RootsMagic Import.fhf file that seems to be causing the error. https://familytreehelper.us/RootsMagic-Import.zip

thanks

Matthew

[Mark1834]

Thanks Matthew, that's really helpful.

Two distinct issues:

The first one is straightforward enough. Most Fact Set files have the list of Facts first, followed by the details for each fact. However, for some reason CP have structured the RootsMagic Import fact set the other way around - the list is at the end of the file after the details, not at the top! The plugin sees the apparent discrepancy, and gives a friendly warning about the file causing the problem. It is an easy correction to allow the list to be anywhere in the file.

The second is a little more puzzling. When FH imports an RM database, it gives a choice between treating Alternate Names as Facts, just as Names (which is the GEDCOM-compliant FH way of doing things), or both. If you choose to create a Fact, the RootsMagic Import fact definition file includes an Individual Attribute _ATTR-ALTERNATE_NAME-IA, but no details are defined for it and it does not appear in the list of Facts available in the FH user interface. This is the case for your file linked above, so you probably selected the recommended default of Import as Names and Facts.

It was this inconsistency of a Fact with no details that caused the plugin to crash with the error shown.

This appears to be a bug in the import process. In fact, the description in the FH Help file may be incorrect. It says that In RootsMagic, each person has one primary name, and other names are recorded as 'alternate name' facts about the person. However, while it is certainly true that every RM database file has a standard Fact called Alternate Name, as far as I can see this is never used. If you add an alternative name to an individual in RM, it is not recorded in the EventTable, but as a separate entry in NameTable.

I'd welcome other views from those skilled in the dark art of FH Fact Sets. Have I missed something? I won't raise a ticket yet, but let's see how the discussion develops...

[Mark1834]

Thinking about it further, irrespective of whether the odd formatting of the imported Alternative Name fact is by design or a bug that will be fixed in a future upgrade (and I'm leaning towards the latter), the plugin still has to cope with existing files that have already been imported.

The attached update should fix both the issues that Matthew identified, so please try it out. I won't submit to the Store until we have clarity over the background, as the plugin comments may change, even if the code doesn't.

[tatewise]

I tend to agree with you Mark, that the 'upside-down' format for the RM FHF file is a bug.
I have not checked but I suspect my Change Any Fact Tag and other plugins would baulk at that format.

The other scenario of custom facts in the database without associated fact definitions in FHF files is normal.
Prior to the Project direct import option, all imports were via GEDCOM and they hold no fact definitions.
So every imported custom fact has no associated fact definition. That scenario should be tolerated by any plugin.

[Mark1834]

The “upside down” fact set and inconsistent handling of RM alternative names has been “passed to the developers for review”, which is CP’s tier 2 answer (tier 1 = “will be fixed in next update”, tier 3 = “this behaviour is by design” ).

The problem has existed for months without being noticed, and so far nobody has downloaded the plugin fix, so I’ll leave it for a while before updating the store plugin in case they do come up with a modification that needs additional changes.

[MFriend]

Hi Mark:

I completely forgot about this forum thread. I tried out the revised plugin and it works perfectly.
I did get a pop-up that I was converting an attribute (the residence) to an event (census) so I read the help file.
The place, address, sources are all good after the conversion... thanks.

Matthew

[tatewise]

Mark, the plugin should make an exception of the Residence Attribute (as GEDCOM does) because it cannot have a Value, so can always be converted to an Event without a problem.