Family Historian User Group

So my suspicion is likely correct...

What do you think of Martin's suggestion to avoid using the fhConvertUTF8toANSI(...) function?

I was about to ask why you were converting to ANSI, but suspected it's for backward compatibility?

When I was writing International Character Handling for Plugin Authors, I concluded that the safest option was to stick with UTF8 throughout.

It is not just backward compatibility but also in order to use certain libraries that only support ANSI file paths:
Lua File System (lfs) library to get file attributes such as modification date.
tableloadsave library to load and save table structure 'sticky' settings.
IM: Digital Imaging Toolkit library for file content editing such as cropping and conversion from png to jpg, etc.

Anyway, in Jeff's case, assuming the Language setting is the problem, it seems he has two options:

1. Change the Language setting to English.
2. Currently only 5 of his files use accented characters so he could just change those 5 file names and avoid all accented filename characters in future.

tableloadsave library? Is that available as a library?

The article I pointed to points out the problems with lfs etc. but the solution is to use fhFileUtils which you can't for backwards compatibility (although you could crib the code). It also suggests a workaround for IM.

tableloadsave is available from http://lua-users.org/wiki/SaveTableToFile.

My plugins use that file-copying workaround for tableloadsave and LFS and IM, and anything else that needs it, but only if the file path is not ANSI-compatible to avoid lots of unnecessary file copying, that for large Projects with thousands of Media files can waste a lot of run time and possibly Lua memory.
So it uses fhConvertUtf8toANSI to identify ANSI-compatible file paths.

That's the code I though you were taking about, but as confused when you called it a library. Shouldn't be too hard to make it utf8 compatible.

Understood re volume of copying; and renaming the file temporarily would be a risk (albeit a small one).

Hi Mike,

Thank you and the CP (Simon?) for you time in looking into this!

My PC is a NEC Japanese made, but with Windows 10,
I have the language and the admin. settings set to English U.S. ,
so that I can read all the programs and work within the PC in English
BUT
I do have the locale set to Japan, so that the time and a few other features
are local to where I am.
I don't have a problem with setting everything to English.
I will try that and respond back here,
hopefully indeed I will get the desire effect.
Thank you again!

Jeff

Martin from CP has further responded with:

We have now clarified why fhConvertUTF8toANSI sometimes fails when the system locale is Japanese. This will be fixed in the next update. So if your user does not wish to change his system locale, the alternative is just to wait for the next update.

So Jeff you now have a third option of waiting for the next FH version release.

Anyway, this string conversion problem is resolved and we can focus on your FH==> TNG mediatype blues (21456).

Mike,
I changed all the settings to English.
The result was still the same errors in the fhConvertUTF8toANSI test
But
The gedcom export plugin did finish complete thru.
There were only 324 lines in the gedcom file as it presented onscreen.
Is that correct for over 6400 people?

Notepad++ gives me 296564 Lines when I open the Project file==>Public==>Export==>gedcom.

Is the problem resolved ? (even if I dont use language accent marks, thats ok with me)

I can in my case get a Gedcom to export to TNG now and buy FH7 ??

Please advise, so I can move on from this thread too!

Thanks,
Jeff

tokyojef wrote: ↑

17 Jan 2023 13:43

I changed all the settings to English.
The result was still the same errors in the fhConvertUTF8toANSI test

After changing the system locale to English did you Restart your PC as advised by Martin?
If changing to English does not fix the problem then maybe it is not resolved after all.
Please post a screenshot of the settings you changed.

tokyojef wrote: ↑

17 Jan 2023 13:43

The gedcom export plugin did finish complete thru.
There were only 324 lines in the gedcom file as it presented onscreen.
Is that correct for over 6400 people?

Notepad++ gives me 296564 Lines when I open the Project file==>Public==>Export==>gedcom.

Remember the latest plugin version I gave you does not fail but lists errors at the top of the Result Set on completion.
Not sure what you mean by "only 324 lines in the gedcom file as it presented onscreen".
Are you referring to the Result Set displayed in FH on completion? That is not a GEDCOM listing!

tokyojef wrote: ↑

17 Jan 2023 13:43

Is the problem resolved ? (even if I dont use language accent marks, thats ok with me)

The problem is not fixed in the current FH v7.0.18 release but we think we know the solution.

1. Change the system locale to English (we think, but your experiment suggests not).
2. Don't use accented characters, which side-steps the problem.
3. Wait for the next FH release ~ probably v7.0.19.

Thanks mike!
1. I will restart the PC then.
2. not use accent marks (until the new update)
3. if so, then I am safe to purchase FH7 or still wait awhile?
Jeff

If you purchase FH V7 then you are eligible for all future updates to FH V7 for free, which includes a fix for this problem.
( i.e. until FH V8 is released, which probably won't be for several years, and will be offered at a discount to existing users. )

Thanks Mike for that.

I looked again at my setup.
Since I have hardware device differenceswith a NEC brand PC,
I have had to keep the keyboard input set to Japanese.
everything else is in English.
I use a Japanese PS/2 Keyboard (106/109 Key Ctrl + Eisuu)
This may have some bearing or no on the issue.
Jeff

The Administrative System Language for non-Unicode programs (system locale) display setting is quite separate from the Keyboard input setting.
Assuming you set the system locale to English and restarted your PC, does the 'String conversion failed' error still occur?

Mike,
Yes still a fail.
Language=English
Admin advanced setting (apply to welcome screen and app dialogues)=English
Locale=United States English

If I dont use any Language accent marks I am ok for the gedcom export to process all the way thru.
I will go with that for now.