* Export Gedcom plugin project changes (bug?)

[Mark1834]

I was a little concerned after running the Export Gedcom plugin to see that my project had been changed, as "Undo Plugin Updates" was enabled, and FH prompted me to save changes on closing. It is the latest plugin version with all options apart from the destination folder still at default, as it was a test run to become familiar with its operation before using it in anger.

Comparing the saved project file before and after showed that the only change was to the _USED tag in the header section, where it had incremented the value stored for Source Templates. Before running the plugin, it read
1 _USED I1463,F317,N259,S3413,R6,U1,B0,O3413,P1021,T22,
and after running it was
1 _USED I1463,F317,N259,S3414,R6,U1,B0,O3413,P1021,T23.

This was confirmed by creating a new source template record with each file, and the record id differed by one.

It's an odd thing for an export plugin to do, so presumably it's a bug that's crept in rather than by design?

[tatewise]

Perhaps the plugin needs to make that effect it bit more obvious but it is mentioned and it is relatively benign.

In the closing Memo it says:
NOTE: Use Edit > Undo Plugin Updates to avoid increased Record Id.

It only applies to Projects with Templated Sources and is explained on the Extar Options tab Help page for:
Templated Source 1 _SRCT: Convert to Notes
This option increases the Record Id for new Source and Source Template records but can be reversed after closing the plugin by using the Edit > Undo Plugin Updates command as advised in the closing Memo.

The plugin uses temporary records to compose the formatted Notes and deletes them afterwards, but the side-effect is that the Record Id are increased by one. I've asked CP to provide a plugin function that can perform the Undo Plugin Updates so that such benign changes are never noticed by the user.

[Mark1834]

Thanks - clear, and I’d missed the extra warning in the closing menu compared with running in the Sample Project.

Couple of suggestions for you to consider as you see fit…

• There are no visual clues in the final memo to indicate that the user needs to pay more attention. IMO, it would be much clearer to use a standard IUP message box with the appropriate icon - blue information for normal use, yellow warning to highlight changed data. If you want to keep the additional options, at least model the custom form on the standard Windows design and use the icons.
• I can see the benefits of an fhUndoPluginUpdates() function to give an easy way to back out of changes where necessary (e.g. an error condition), but there is a risk of it being misused. I’m not sure that making unnecessary changes to user data and then reversing them would be regarded as best practice. Granted there are probably historic reasons for doing it that way here, but extracting the template fields and writing to GEDCOM on the fly feels very doable and would probably be the preferred method for a new plugin.

[tatewise]

• There are no visual clues in the final memo to indicate that the user needs to pay more attention. IMO, it would be much clearer to use a standard IUP message box with the appropriate icon - blue information for normal use, yellow warning to highlight changed data. If you want to keep the additional options, at least model the custom form on the standard Windows design and use the icons.

The final Memo does use an IUP message window. I don't understand what you are suggesting for icons and colours.
I agree that some icons and colours would help.

• I can see the benefits of an fhUndoPluginUpdates() function to give an easy way to back out of changes where necessary (e.g. an error condition), but there is a risk of it being misused. I’m not sure that making unnecessary changes to user data and then reversing them would be regarded as best practice. Granted there are probably historic reasons for doing it that way here, but extracting the template fields and writing to GEDCOM on the fly feels very doable and would probably be the preferred method for a new plugin.

How could fhUndoPluginUpdates() be misused?

There is nothing historic about what the plugin is doing. In order to render each of the Template Formats (Record Title, Bibliography, Footnote, Short Footnote) the fhSrcEnableAutoTitle() function must be used that only operates on a Source Record Title with a link to a Source Template. So the plugin uses a dummy Source record linked to a dummy Source Template record and copies each Format in turn to the dummy Source Template Title Format and reads the dummy Source record Title. There is no other way and Helen had to show me that way.

Previously, the plugin performed the formatting in the Project's actual Source records and Source Template records which changed their Last Updated date/time stamp. I believe using and deleting dummy records is far better.

[Mark1834]

On the basis that a picture is worth a thousand words...

Capture.PNG (153.24 KiB) Viewed 356 times

There is nothing in the first pair of menus to highlight that the second one needs a bit more attention, and if you are used to seeing the first style, it would be easy to miss the extra line of text in the second.

For the second pair, it is immediately apparent in the second case that user attention is required. There is a clear explanation of what the potential issue is in user language and how to fix it, without having to consult the extensive online help. We've dispensed with the options to open the file in another application, but IMO they distract from the main message, and anybody with sufficient tech-savvy to be interested in the detailed file contents probably knows how to open File Explorer or their favourite text editor anyway!

There are not many absolute rights or wrongs in UI design, but I tend to work on the principle that if my menus and messages don't look like they were designed by CP as an integral part of FH, I've probably done it wrong, but YMMV - it's just a hopefully constructive suggestion for you to take or not as you see fit...

[Mark1834]

In order to render each of the Template Formats (Record Title, Bibliography, Footnote, Short Footnote) the fhSrcEnableAutoTitle() function must be used that only operates on a Source Record Title with a link to a Source Template. So the plugin uses a dummy Source record linked to a dummy Source Template record and copies each Format in turn to the dummy Source Template Title Format and reads the dummy Source record Title. There is no other way

OK, I see where you are coming from. My templates tend to be just a collection of field codes, fixed text and punctuation, so reconstructing the Footnote, Short Footnote and Bibliography from a combination of the Source and Source Template records would be fairly straightforward without having to resort to that trick. Once somebody starts using the more complex formatting options, replicating that via plugin would be possible in principle, but far more work than it's worth, so the workaround makes sense in that context.

[tatewise]

Yes, coping with all the possible functions, data refs, qualifiers, and style codes would be a nightmare
The BOOK and TITLE styles involve a Windows Registry lookup.
Any new features would require almost instant enhancement to the plugin.