* Export Gedcom File problem with Gedstar Pro

[BillH]

I am running into a problem trying to create a file for Gedstar Pro using the Export Gedcom File plugin. These are the options I specified. The only one I changed was to not include multimedia. No changes were made on the other tabs.

I am using version 4.6 of the plugin.

image1.jpg (87.24 KiB) Viewed 2575 times

When I run the Gedstar Pro conversion program using the gedcom created by the plugin, I get a fatal error.

Line 463386 in the GEDCOM file does not start with
a numeric level number. Check your GEDCOM export procedure
and export a new GEDCOM file.
Fatal error "Line #463386 in GEDCOM file does
not have a level number" in file TCGedParse.cpp at line #209

This is what the original gedcom looks like before running the plugin.

2 CONT
2 SOUR @S90@
1 NOTE Could this be Charles and Margaret's son?
2 CONT
2 CONT Death Record Detail... View the record image (1185 Kb)
2 CONT Name: Harold B./Hancher

This is what the output from the plugin looks like.

2 CONT
2 CONT Cited Source: [S90] Hinshaw Family Association
2 CONT Cited Source: [S1837] West Virginia Division of Culture and History
2 CONT Cited Source: 3 NOTE
_FMT
1 NOTE Could this be Charles and Margaret's son?
2 CONT
2 CONT Death Record Detail... View the record image (1185 Kb)
2 CONT Name: Harold B./Hancher

The line 463386, which the error referred to, is the line which contains only "_FMT".

Do I have a setting wrong in the plugin or is there an error with the plugin or something else? Let me know if I can provide any more details on the problem.

Thanks,
Bill

[tatewise]

Sorry about that Bill.
I have been able to repeat the symptoms with a rich text Citation Note associated with a Source.
It is the rich text Note that has the _FMT tag and is not handled correctly in this specific scenario.

So I should be able to fix that in the next plugin version. In the meantime here are some workarounds...

In your example, the NOTE appears to have no text, so could be deleted, if you can find it.
It must be on a Citation associated with the Source: [S1837] West Virginia Division of Culture and History.

Alternatively, just delete that rogue _FMT line from the exported GEDCOM.

[tatewise]

It was quite easy to fix, so try the attached Export Gedcom File plugin Version 4.6.5 Date 06 Nov 2021 ZIP file.

It also has the new features described in Export Gedcom File plugin new features (19799).

[BillH]

Mike,

I was able to find the note on the citation which was empty.

I have a question though. I have never used any rich text anywhere. If I created an empty note, how would it have been created as rich text? Is there any way I can tell by looking at it that it is rich text?

I will try the new version of the plugin today as a test and will then just delete the note as it is empty anyway.

Thanks,
Bill

[tatewise]

You cannot easily tell just by looking whether a Note is in rich text mode or not.
You only need click the [...] button on its right to open the rich text word-processor style editor and it will become rich text.
In the GEDCOM, the only difference is the NOTE tag is followed by a _FMT tag unless you add some rich text formatting.
So a search through the GEDCOM for "_FMT" with a plain text editor will tell you if any others exist.

The bug in the plugin was when Notes were being synthesized from other data structures.
That other data was not being subject to the Rich Text Formatting option chosen in the plugin Basic Options tab.
I'm glad you discovered it because its impact could be quite widespread. So thank you
It is something I'd overlooked as part of the changes due to FH v7.0 rich text feature.

[BillH]

Mike,

Version 4.6.5 did create a gedcom without the _FMT line. The Gedstar Pro conversion worked without any errors. Thanks for updating the plugin.

Interesting about rich text. I never use any actual rich text formatting, but I have a lot of _FMT lines in my gedcom file. Whenever I double click on a note to edit it, I get the rich text word-processor style editor. Is there a way to turn that off and just get a plain text editor instead?

I have a question about the gedcom file created by the plugin. When I run the plugin and have it create a file and use the same name as an existing file, it replaces the file but does not update the date or time of the file. This can be confusing because looking at the file in file explorer I can't tell when the contents were actually created.

Is this standard Windows operating procedure? Logically it seems like the date and time should be updated when the file is overwritten.

Thanks,
Bill

[tatewise]

I don't think there is a way to inhibit the rich text editor window, but if you don't use any formatting features the only effect is the _FMT tag, which is no worse than all the other FH unique tags.

File Explorer can be a bit confusing regarding dates.
Each file has at least three dates that can be seen via its right-click Properties, i.e. Created, Modified, Accessed.
It is quite common for File Explorer to show the Date Created by default.
So right-click its column headers and untick Date Created and tick Date Modified.
Then it will show the date that the plugin last updated the files. That setting should 'stick' to the folder.

[BillH]

I know about the different columns in file explorer. What I was confused by is that if I create a file in say another program that will overlay an existing file I get a warning saying the file already exists, do I want to replace it. When I say go ahead and replace it, the date and time changes.

I thought maybe the plugin would also update the date and time since I thought it was replacing the existing file not just updating the existing file. It must be the way the plugin works which causes it to be an update rather than a replace.

Thanks,
Bill

[tatewise]

Yes, the way the plugin works is it opens the target GEDCOM file for write access.
If it does not exist it gets created, otherwise, it is re-opened and overwritten, so only the Modified Date is changed.
I imagine in the replacement case you quote, the original file is deleted before the new copy is written.
The plugin could delete the old GEDCOM before it starts writing the new one and that would update the Creation Date.
It seems it would be helpful if I made that simple change to the plugin.
I always display the Modified Date in File Explorer, so it is not a problem, and is better for understanding when any other files are updated by editors, etc, (nothing to do with FH).

[Mark1834]

Gents,

In my experience, the _FMT tag appears in the FH Project GEDCOM file only if Rich Text is used. If all text options are kept at Auto the contents are saved as plain text with no custom tags.

Unfortunately, left to its own devices, FH does not always default to Auto, and applies formatting uninvited. I reported it to CP a while back, but it has not been fixed yet.

[BillH]

The plugin could delete the old GEDCOM before it starts writing the new one and that would update the Creation Date.
It seems it would be helpful if I made that simple change to the plugin.

Mike,

Thanks for the explanation. I know for me this would be a nice change, but I don't want to speak for others. If anyone doesn't like this change, I can continue to live with it the way it is.

Thanks,
Bill

[BillH]

Gents,

In my experience, the _FMT tag appears in the FH Project GEDCOM file only if Rich Text is used. If all text options are kept at Auto the contents are saved as plain text with no custom tags.

Unfortunately, left to its own devices, FH does not always default to Auto, and applies formatting uninvited. I reported it to CP a while back, but it has not been fixed yet.

I'm not sure I completely understand. I know I have never used any rich text anywhere within FH 7 and I have quite a lot of those _FMT tags in my GEDCOM. I think the most that could be happening is that I am opening a note in the rich text editor, but not using any rich text features.

What is the Auto you are referring to? I am not familiar with that.

I have never noticed any formatting applied to any of my text.

Bill

[tatewise]

I think the Auto that Mark is referring to is the Automatic font top left, which should not need any rich text formatting.
So if no other features are chosen, it should need no rich text effects at all and thus no _FMT tag.

[BillH]

Mike,

OK. I find for all my notes that it just uses my default font specified in preferences on the Notes tab under Default Font (Shared with the Property Box).

I agree it should not need the _FMT tag if I don't use any rich text. It is too bad it is added to the Gedcom anyway.

Bill

[tatewise]

Yes, that is what Automatic means. So no rich text formatting.
But as Mark says, FH sometimes still adds the _FMT tag for no reason.

[BillH]

Mike,

Oh, I was confused. I thought he meant that it added actual formatting of some kind rather than just adding the _FMT tag.

Bill

[Mark1834]

That’s what I did mean. In my experience, FH sometimes adds its own formatting. Usually it’s Segeo font at 9.5pt, and my speculation was that it is a Visual Studio default that is being invoked.

Easiest thing is to check your GEDCOM file. Is the _FMT tag there in isolation, or are there other formatting commands as well?

[BillH]

Mark,

I've never seen anything like that. All of my tags are of the form

n _FMT 1

where n is 1, 2, 3, 4, or 5.

No other formatting commands present.

Bill

[Mark1834]

Ok, so if there are no <font=....> or </font> tags in your GEDCOM, it’s not the same “feature”.

[BillH]

Mark,

Again I was confused. I thought there would be something on the _FMT line itself.

I do have <font> and </font> tags in my gedcom. They appear to be mostly or all <font="Segoe UI",,0>

In addition, I have a lot of <i> and </i> tags in my file.

These are in notes that I cut and pasted into FH a long time ago, before FH 7. Those would have been plain text as rich text didn't exist in FH at that time. I wonder why they now have rich text tags.

So I guess I am getting fonts applied to my notes.

Bill

[Mark1834]

Copied from RootsMagic? They use <b></b> and <i></i> for bold and italic formatting. So it looks like you have a combination of artefacts from your old app, plus some quirky FH formatting.

[BillH]

Mark,

No, I've never imported from RM, but I did use Reunion a long time ago. The <i> and </i> may have come from there. The text doesn't actually end up displaying as italic in the text editor window, the tags just show up as part of the text.

The <font> and </font> are on records that were entered directly into FH and were never in another program. The text does show as Segoe UI font in the text editor window. I've never noticed that before. A lot of these came from cutting and pasting from Find a Grave into FH and I always paste without formatting in FH 7 and of course there was no formatting before FH 7. What is weird is that Find a Grave doesn't appear to use that font on their website so I'm not sure where this came from. I don't remember ever using Segoe UI as my font (although I might have tried it and have just forgotten).

Oh well... no big problem... just weird. I'll go ahead and delete these tags from my Gedcom and all will be well till next time.

Thanks,
Bill