Family Historian User Group

Here are some further thoughts:

1. Ok, but that must be conveyed to the user, otherwise on the Facts tab, it appears as if the Value has been deleted.
   That could easily confuse the average user who may be unaware of such additional Notes.
2. I think it should be tweaked, as imported custom facts will probably be <undefined> and fall into this anomaly.
   Therefore, for imported Projects, there could be many such facts out of order.
3. Yes, so it does and should be reported to CP as a bug in both the fhGetDisplayText() and fhGetItemText() functions.
   RESI 'Residence (family)' is displayed correctly but not CENS 'Census (family)' strangely!
4. There are other side-effects that I did not mention as I thought fhMoveItemBefore(ptrNew,ptrOld) was a simple fix.
   1. Reports only auto-sort facts with Dates. Undated facts will move to the end of their Normal Time Frame.
      Users may have gone to some length to organise the order of undated facts.
   2. Assume a user has a data ref such as INDI.OCCU[last] or [last-1] to refer to the last or penultimate Occupation.
      If any fact is changed to an Occupation then it will become the [last] one even though its Date is not the latest.
      That will upset whatever purpose the [last] index is used for and may affect data integrity.
   3. There may be others such as the Diagram looping index [1+] probably displays in database All tab order.

You’re doing it again - editing your post to correct your comments as I’m reading it! It’s getting late now, but I’ll probably look at it tomorrow. My first thought on the complexities of item 4 is that if somebody has gone to great lengths to customise their fact order and sequencing, they probably shouldn’t be messing about with it via a plugin!

I'm relaxed about 1 and 2 at the moment - they are minor cosmetic issues that I will update in my master copy, but they are not worth posting a new version at the moment. At worst, it will list all custom facts in date order, followed by defined facts, so still easy enough to find what you are looking for.

On 3, you've deleted your analysis of the "problems" my code has, so presumably we agree that this is just a minor inconsistency in how FH displays the Family Census compared with the Family Residence and doesn't impact functionality or data integrity.

4 is more interesting. It is clear that [last] just means "last in the database", not "latest", as the default order can be overridden even for similar dated facts. For the (probably very small number of) cases where it might matter, the solution seems to be to emulate what FH does - if there are similar facts to the new one, place it in chronological order. It's a bit more code, but not difficult to do. The obvious comparison is with the Change Any Fact Tag plugin. How does that deal with maintaining database order when changing a fact? I had a quick look at the code, but it's far more complex than mine, so difficult to get a quick overview of how it works.

Regarding point 3, on re-examining your code there is a logical issue with the GetFactLabel() function.
The tblAllFactHeadings table can contain all four of the following in any order:
Census (family) => "[FCT-CENS-FE]"
Census => "[FCT-CENS-IE]"
Residence (family) => "[FCT-RESI-FA]"
Residence => "[FCT-RESI-IA]"
So the GetFactLabel() function can return either form for CENS and RESI tags, because the FE, IE, FA, IA are not checked.
That then impacts the Sort Tag which could upset the sort order.

Regarding point 4, the solution is trivial, as I suggested, simply insert FH API fhMoveItemBefore(pNewFact, pOldFact) on line 172 in your plugin, which is what the Change Any Fact Tag plugin does.

OK - 3 is also just cosmetic, as it is impossible to change either a census or residence to one of the wrong type (i.e. family to individual or vice verca).

Keeping the fact order is fine for dated facts. However, both plugins can upset a custom order for undated facts (they cannot possibly know why a user has ordered the facts as they have), so "first" and "last" could be invalidated after a change. It makes sense to include a warning to that effect for the small number of users it is likely to affect. It's here in this thread while it's just a FHUG plugin, but if it gets submitted to the store, I'll include that in the help page. It is probably worth adding to the Change Any Fact Tag help as well if it is not there already.

All the changes were fairly minor, so I've updated my working copy. It's not worth posting another version until we get feedback from users, just in case there are more significant issues that we have missed.

(post updated).

Mark, you misunderstand the simple solution to point 4. No sorting by date is needed.
The Change Any Fact Tag plugin does NOT upset the order of any changed facts whether dated or undated.
Your plugin can easily do the same by making the edit I suggested earlier.
i.e. Insert at line 172 the statement fhMoveItemBefore(pNewFact, pOldFact)
It is really that simple. I have made that change and it works perfectly for any fact, retaining the database position.

There is no need to sort facts by Date or perform any form of sorting. Just insert that standard FH API function.

pOldFact points to the original fact position.
pNewFact points to the newly created fact at the end of the facts.
fhMoveItemBefore(pNewFact, pOldFact) moves the position of the new fact up to just before the original fact.
So when the original fact is deleted the new fact will take its position in the GEDCOM database order.
No sorting is necessary. No dates are involved. Just a simple pointer move operation.

It is true that if the new fact is in a different Normal Time Frame to the original fact and is undated, then it may sort into a slightly different position, but dated facts and most undated facts will stay put.

There are other simplifications of your plugin that I could offer if you are interested.
e.g. There is no need to insert and remove the Sort Tag on the front of the display text around lines 80 to 93.

Mike, you misunderstand the first sentence of my final paragraph. I said all the changes were minor and I’ve updated my working copy, so the extra explanation was unnecessary.

Demonstrating the other point I was making is easy. Add three undated occupations. You know which came first and last, so designate the custom order as required. Now change another undated fact to occupation. Queries that pull out the first and/or last occupation will now give a different result. It must be so, as neither plugin has any understanding of “first” or “last”, so don’t respect it. You (perfectly reasonably) pointed out that queries for dated facts could be disrupted, but I’m adding the additional point that overall sequencing of undated facts can still be compromised. It’s easily correctable, but worth pointing out to users.

Code “optimisation” not required, thank you. We need a plurality of coding styles. Very few, if any, of our authors are trained IT educators. I’m deliberately trying to do something a little different. It may take a few microseconds longer to run or a few extra bytes in disk storage, but I prioritise clarity very highly, even if it is more verbose. This is open-source software, so I want my scripts to be copied and adapted. For that to happen, they have to be readily comprehensible.

Sorry, I did misunderstand your comments. I'll continue testing.

I didn't mention code optimisation but simplification that may also be more comprehensible.

Now that the coding for this plugin is more or less done (bar any reported user problems) I was doing some housekeeping to tidy up my Fact Types files. I noticed that there is also a collection of Standard fact sets under Program Files (x86)>Family Historian>Fact Types (i.e. in the actual Windows program folder, not the data folder). These seem to be older versions of the provided sets, as FH6 includes v1, v2 and v3 versions, and FH7 adds v4 and v5.

I'll leave well alone, as it is never a good idea to change the program folder manually, but can anyone hazard a guess as to why CP have included these?

I suspect they are to do with when FH needs to upgrade existing fact sets when upgrading from an earlier version, to decide if the user has customised the facts or not.

I think the C:\ProgramData\Calico Pie\Family Historian\Fact Types\Standard\ files are derived from those C:\Program Files (x86)\Family Historian\Fact Types\ files and may supply details to the Tools > Fact Types > Edit > Old Versions... button.

No other issues have been raised, so I have corrected the minor cosmetic bugs discussed above for Version 0.3. I have also taken the opportunity to upgrade the user interface to make it more functional. The original version could be produced with much less code, but was relatively light on customisable features.

Rather than letting the user define more or less any conversion, then complain if it was invalid, the new interface guides you through the change and only presents valid options. For example, if you select an Individual Event to change, existing Individual Attributes are greyed out and only Individual Events and Attributes are displayed for the new fact, with Family Events and Attributes being hidden. The action button is disabled until a valid selection is made. The only conversion that is not checked before selection is witness roles, and you will continue to get a detailed message describing which roles are missing from the new fact definition if there is a problem.

I have also restructured how data are stored internally to make it more logical and hopefully easier to follow for anyone wishing to crib the code in the future or modify for your own custom version.

As ever, try it out on a copy of your project first, just to be on the safe side.

I keep an eye on my more significant FHUG plugins to see if any of them have an unusually high (or low!) number of downloads, and this one stands out as being significantly more popular than I would have anticipated.

I have therefore submitted it to the Store, and the Change Specific Fact Tag plugin is now available for download. I have deleted the prototype from the posting immediately preceding this one.

The first Store version is based on the last FHUG prototype, which has been live for some months without raising any issues, with a number of minor refinements:

• Correcting an unreported bug whereby some Facts could be omitted from the list of available new Facts due to inconsistent formatting of Fact Set files by CP. Presumably they have tweaked the code that produces the files at some stage without going back and recreating the Standard and Extended sets.
• Addition of a simple help page describing how to use the plugin.
• Full support for FH7 custom fonts and zoom and associated resizing, so the plugin looks and behaves just like any other FH form. IMO, this should be a standard feature now for new and updated Store plugins when running under FH7, as it is very easy for authors to incorporate.

Given these enhancements, all users are recommended to upgrade to the Store version.

Mark, that is a very handy plugin, but may I correct its description of the Change Any Fact Tag plugin.
The descriptions imply no tag selection is possible, whereas selection by Value, Date, Place or Records via filters is provided.

On the Download page, please replace:
"Instead of globally changing all instances of a defined tag to a new value"
with
"Instead of changing selected instances of a defined tag in bulk to a new value"

On the Help page, please replace:
"rather than automatically changing all instances."
with
"rather than changing selected instances in bulk."

I will add a reference to your new plugin from my plugin's Download page.

Agree - yours is a better description. Help is corrected already, and the new download text will appear when it is approved by the plugin police.

To save me wading through, can somebody clarify if an item is still required on the Wish List for this?

Don’t think so, if we accept that FH gaps can be filled by plugins.

There's precedent...

Shouldn't there be a general "wish list item" that plug-ins should be reviewed with a view to incorporating them into "main code"?

Plug-ins are not seamless - yet?

I'm not sure that telling CP that they ought to review all plugins regularly would achieve anything.? Or am I misunderstanding?

Well I may be misunderstanding you!

if you are implying that CP would always be reviewing plug-ins with a view to incorporating their functionality into main code, so there is no point in requesting that they do so, perhaps we don't need to ask.

But plug-ins are either useful extensions of functionality or "work-a-rounds" to get round issues with existing functionality. The later I would hope would prompt CP to consider how they have implemented a feature. The former would I hope prompt them to think whether the extension of functionality is sufficiently useful to sufficient of their prospective user base to incorporate it into code they maintain.

Plug-ins are often very clever, but they are not fully integrated into the program requiring some level of manual intervention and for new users do not represent an obvious way to access certain bits of functionality.

Mark1834 wrote: ↑25 Jul 2022 19:44 Don’t think so, if we accept that FH gaps can be filled by plugins.

Surely all but the most obscure or specialist plug-ins should be thought of as stop gaps pending incorporation of their functionality into main code?

davidf wrote: ↑25 Jul 2022 21:21... Surely all but the most obscure or specialist plug-ins should be thought of as stop gaps pending incorporation of their functionality into main code?

Surely it has to be a question of priority - why duplicate functionality available elsewhere if you're not adding any value to the existing software estate?

Well stop-gaps can be in place for some time!

I would have thought however that the developers would look at what plug-ins there are and go through the considerations I mentioned in my previous post "to think whether the extension of functionality is sufficiently useful to sufficient of their prospective user base to incorporate it into code they maintain"

I had the very same need last week: wanted to change Occupation facts to Employment, so I read this thread with interest. Looks like I made the right decision to just copy the fact text to a text editor and then paste it into new facts. Always glad to see what you all are thinking/working on for FH7.

BEJ wrote: ↑27 Jul 2022 11:05 I had the very same need last week: wanted to change Occupation facts to Employment, so I read this thread with interest. Looks like I made the right decision to just copy the fact text to a text editor and then paste it into new facts. Always glad to see what you all are thinking/working on for FH7.

Perhaps you missed the relevant posting, but there is no need to copy & paste anything external to FH.
The Change Specific Fact Tag plugin in the Plugin Store will change any single nominated Fact.
The longstanding Change Any Fact Tag plugin will bulk change all, or a selected subset of, Facts from one type to another.

I am interested in why you would want to change standard GEDCOM Occupation facts that are understood by all products to custom Employment facts that may be less well understood.