Family Historian User Group

I carry out my research by way of Seperate Trees and therefore only have a persons index for the persons in that Tree.Is there any way I am able to produce a master index for all the seperate Trees

One way would be to do a csv export using a query from each tree and then combine the CSV's in Excel or similar.

I have moved this to the FH General Usage Forum as it is not (yet) a New Wish List Request.

Presumably, by Separate Trees, you are talking about separate Projects?

An alternative technique would involve a Plugin that interrogated all the GEDCOM files.

Grahame, what exactly would you want to be listed in such an index?
Clearly, the name of each person, and their Record Id with the Project name, but what else?

Do the same people sometimes exist in more than one Project Tree?

My Trees are all seperate projects and I have for sometime had a seperate CSV file but it is somewhat tedious having to prepare the seperate index.I would like a Master Index to include the Date and place of Birth.My CSV File also includes the string name which identifies the relevant Tree but this may be more difficult to include in an Index which is automatically ceated by FH.If a name appears twice in the Index it would probably indicate that a merger of 2 Trees is required.How do I put my request in the Wish List for a later version of FH.

If a workable solution is not forthcoming, then this posting can be moved back to the New Wish List Request forum and a Wish List item created, but this is a very niche request so don't expect CP to implement it quickly.

Let me look at a Plugin solution...

Thanks for your help -I await to hear about a plugin

I would very much like to be able to search for a person name across several fh projects.

Because fh uses text files, it is possible to use the Windows 10 search but it seems to take a very long time.
I tend to give up and check the projects themselves.

I have three place projects (based on census location) plus a fourth for anyone left over. I occasionally find someone who is in 2 projects, a duplicate, and in this case I leave the name entry with a cross reference to the Project where the data is entered.
I would not want a complex excel export and comparison as I am adding new names almost daily.

I have a prototype plugin that produces a multi-project index for you to try. It only runs in FH v7.0.
It creates a Result Set with four columns as shown below.

1. Rec Id = Project identification letter and Individual record id number
2. Name = Name of Individual or a Project name
3. Birth Date = Date of birth of Individual
4. Birth Place = Place of birth of Individual

Click on any column heading to sort into order.

Attachment Multi-Project Person Index plugin Version 0.1 Date 11 Oct 2021.

Here is a revised Multi-Project Person Index plugin Version 0.2 Date 12 Oct 2021.

It fixes some minor mistakes I spotted and trials an improved variant of a library function.

Thanks Mike,This plug in is really useful and you should publicise it more -I suggest that you notify The Guild of One Name studies of the availability of this plug In for Family Historian Users.Regards,Grahame Matthews

Thank you Grahame.
If you are familiar with the 'Guild of One-Name Studies' then may I suggest you publicise the Plugin there.
You probably understand its benefits to such users better than I do.

It will remain available here for anybody to download. They don't even have to join the FHUG.
If it gets popular enough then I will publish it in the Plugin Store.

I'm surprised there has been no response from the others who have downloaded the plugin.

tatewise wrote: ↑

15 Oct 2021 13:28

I'm surprised there has been no response from the others who have downloaded the plugin.

I’m not. It’s a simple plugin written by an experienced author, so unlikely to have any glaring flaws. In my experience, folks who request a plugin and work with the author to develop it are highly appreciative, but comments from later users are relatively rare, and so far there are only a handful of downloads.

I don’t know what the optimum balance is. Occasional thanks keeps authors motivated, but too much makes threads boring and repetitive...

Dont be cross.
Mike is my hero on fh and yes I need to download it.
But yesterday I started going through a list of 5097 people deported by the Nazis from Baden to Gurs concentration camp.
And I just didnt have a second to spare.

What a star, Mike. Many, many thanks for delivering something I've wanted for years!

I noticed 53 downloads and wonder (as you did) why there has been so little response.
One point, though, unless this got noticed as a recent topic it has no real exposure. Maybe that's how you'd like it to be, but otherwise how about the Plugin Store?

As for the program itself, please forgive the comment... I'd prefer Project Name in an additional column.

Of course, being never satisfied, I could also admit how stunning it would be to have links that could open any out-of-project record in a new FH instance. As well as open a native record in the Property Box. Of course.

You ask in jest, but some of that is actually possible to do. A plugin could open a second instance of FH with a nominated project active quite easily, but they wouldn't be independent so the consequences would be unpredictable to say the least!

A simple alternative if you regularly work on multiple projects is to set up a series of Windows shortcuts, one for each project. Navigate to the project file in File Explorer (project name.fh_proj). Right click on the file and select Create shortcut. Move the shortcut to your desktop, and start FH with that project active by simply double clicking on the shortcut.

You can have as many instances of FH open at the same time as you want, but you should NOT have multiple instances of the same project as that can lead to data corruption.

Is there a command line option to start fh on a specific project focussing on a specific individual? If not, perhaps that should be a wish list item as it would enable other things (e.g. windows shortcuts).

s there a command line option to start fh on a specific project focussing on a specific individual?

Yes, but you need to create an ini file to launch it.

Take a look at
https://pluginstore.family-historian.co ... l-shortcut
to see how it's done.

FH Command Line Parameters
Usage

fh [/INI:<inifile-name>] [<file-name>]

<file-name> can be a GEDCOM file to open


Some Inifile settings (i.e. Window, Record and SuppressWarningsOnLoad) have no effect unless a command line GEDCOM file is specified to open - see 'Format of Startup Inifiles' below.
Format of Startup Inifiles

A startup INI file has the following format:

<record-id> must be the record id of an Individual or Family record to show at startup, and must be prefixed with an 'I' for Individual records or an 'F' for family records. The 'Window' is the startup window.

<diagram-type> is ignored unless Window=DiagramWin, in which case it is required. Specifies the name of a standard or custom diagram type, prefixed with “C-” if it is a custom diagram and “S-” if it is a standard diagram. For example: “DiagramType=C-Ancestors - 4 Gens” (without the quotes).

This plugin has not yet been published in the Plugin Store because it relies on a modified version of fhFileUtils readTextFile function that handles files of any size and was waiting for the fhFileUtils library to be updated.
However, that is taking longer than expected so I may decide to publish anyway.
I was also waiting to see if there was any feedback from users.
All too often I publish a plugin and shortly after a user asks for an extra feature that may be easy to add but involves going through the publishing process again.

I chose not to create an extra column for the Project name because it would be very repetitive and long Project Names would consume a great amount of space. Do you realise that by clicking the Name column you get an alphabetic summary of the Project names versus their letter references at the top? You can then Copy and Paste those cells into a spreadsheet as a cross-reference.

However, adding such a column and some of the other suggestions are feasible enhancements.

tatewise wrote: ↑

06 Jan 2022 12:27

This plugin has not yet been published in the Plugin Store because it relies on a modified version of fhFileUtils readTextFile function that handles files of any size and was waiting for the fhFileUtils library to be updated.
However, that is taking longer than expected so I may decide to publish anyway.

I did tell you not to wait, Mike!

Sorry Helen, but in fhFileUtils library problems (19881) you actually said "Mike, hold off a while".
I did not expect to hold off quite so long although I know there are mitigating circumstances.
Anyway, that is not the only reason for not publishing.

I suggested you published your plugin without waiting for the library to be updated.

tatewise wrote: ↑

06 Jan 2022 12:27

I chose not to create an extra column for the Project name because it would be very repetitive and long Project Names would consume a great amount of space. Do you realise that by clicking the Name column you get an alphabetic summary of the Project names versus their letter references at the top? You can then Copy and Paste those cells into a spreadsheet as a cross-reference.

However, adding such a column and some of the other suggestions are feasible enhancements.

Fair comment, to be sure, though I don't know exactly what you mean by "space". Memory is presumably insignificant compared with the size of project files, while screen estate may be the point. But then columns can be resized, of course.

Yes, I get it we can paste into external programs, but that's a bit like popping out to the shop for a missing ingredient in the middle of rustling up a meal . Grin 'n' bear it if you have to, but not every time.

The ethos of any application should ultimately be to let a user do all the essentials in-app. As I see it, you've done a huge service by extending FH in a new direction that my early posts and recent appeal to Calico Pie have (not surprisingly) failed to bear fruit [Ed.: too many metaphors and slang here].

Things like cross-project activity have been politely and justifiably dismissed in the past. We might see growing interest when more FH users catch on and the posts start flowing (as I dare to predict for the next year). And I dare to beg an expert like you to find time to respond with feature extensions from time to time.

Looking beyond that, multi-"document" editing (sometimes even with tiled windows) is commonplace in so many kinds of app, and idiots like me dream of this coming to a few more apps, FH included. That could finally make your plug-in redundant so you cross off another item from your list of responsibilities after a job well done (and naturally everyone but a few will forget you ever had anything to do with this - c'est la vie).

Why do I care about FH adding this as a feature?

You may recall a post advocating "proxies" for Individuals common to more than one FH project. That's likely to be the case for about anyone who has ever split a project in two. And what happens when you update the common individual's details in one project? Aaaaaargh!

With intelligent integration allowing us to identify/define proxy pairs (including a merge stage flagging discrepancies and allowing them optionally to be resolved), we could have one-place editing. Even to the extent of adding related Individuals, in one project or the other. Even to the extent of defining as many proxy pairs as desired, so managing the view we get in either project. Or "dragging" individuals from one project to the other. When project context-switching is implemented .

Then there is the matter of repositories, sources, fact types and roles, named list names, record flags, place and occupation (virtual) records, plus no doubt some I've forgotten or don't even know about. What a dog's dinner in my case. And (I didn't forget) Individual, Family and all the other Record IDs.

A project-global management system for them could be a real game-changer, especially to "clean up" early projects by merging stuff like source names as well as the more obvious places, etc. Such a system should also offer to renumber Record IDs, globally or across selected projects [I know there are pitfalls, e.g. I use IDs for links in various databases and spreadsheets].

Stuff like that will certainly help when (decades from now?) FH goes relational. Oops .

Sorry, @@Jane, for dumping all that here, a bit of an abuse of the system really.

To me, that sounds like a good supporting argument for the usual forum advice of keeping everything in one big Project. I actually run 3 Projects, but they are unrelated to each other and are in 2 different countries.

A more achievable outcome might be some sort of defined “sub-project” view of your master Project (a filter on steroids).

Based on the information Jane posted and the output from her plug in, I've come up with a general purpose batch file that can be called from the command line with an individual or family id and a project name. It assumes all your projects are in the same projects directory

Extract the command file from the attached zip and save somewhere convenient (mine is in C:\temp).

Change the line set fhprojdir to your projects directory.

If fh has not been installed in the default location, change the set fhprog line.

The command line to run it is:

"C:\temp\Family Historian start.cmd" I33 "Family Historian Sample Project"

where the first parameter is either Inn for an individual or Fnn for a family and the second parameter in quotes is the project name.

I had to change it to open the records window because the focus option doesn't work for families. If you are going to only use it for individuals and want it to open on the focus window change RecordWin to FocusWin in line 2.

Note: I discovered by experimentation you can use a project file instead of the ged file name which slightly simplified the script.