Family Historian User Group

two things CVG, I was reading up on where version 7 is at, seeing if its mature enough for me to upgrade. Am I to understand that the file statistics are returned as a table with some function now? If that is the case, then the wishlist for it can go away, and secondly, this is (because at the time ...

I for one, would propose some wishlist stuff. all the options like date format etc, should be available to plugin programmers, why (since Lua is already slow, and a rather toyish and hobbled language anyway) should a programmer go thru convolutions and machinations to find out how these things are s...

I have not dealt with these at all yet, but wonder if not would work.

you do not actually pay for the api. small users, and believe you me, even if you got 10k places and you run it every other day for a month, it doesn't make the bar.

Mike may tell me I am wrong, but as far as place goes, wouldnt one be better off to make all the standardization first, never mind the lat long stuff, and then run map life facts place fields only, and that would be the most accurate, and then wouldn't fh map use those?

you can certainly merge on that one, if you like...
then you can also edit it to:

Sudbury, Middlesex, Massachusetts, United States or whatever after it is all merged.

and that right there is why you make the big bucks. I stand corrected on my correction.

am I understanding this right? lineage[fhrlt] = swrlt:gsub( "(.*)great (%(%d%dx%)) (.*)", "%1%2 great %3" ):gsub( "great ", "great-" ) at this point, there is nothing ENDING in great. I either have something like: husband's great (09x) grandaunt great (11x) grandaunt ½ great (04x) granduncle and the...

thank you, I am all for the efficiency. my new '_STD_MAT':matRLT require: -- materialize Relation function matRLT(iptr, rptr, ix, __rtv) ix = ix or 1 _ptyp = type(iptr) if _ptyp == 'userdata' then _ptag = fhGetTag(iptr) if _ptag ~= 'INDI' then error(('_STD_MAT.matRLT: INDI ptr unresolved: %s TAG: %s...

function cvtRLT() for fhrlt, swrlt in pairs(lineage) do -- fhrlt = family historian relationship fhCallBuiltInFunction('Relationship', rptr, iptr, 'TEXT', ix) -- swrlt = software relationship swrlt = fhrlt swrlt = swrlt:gsub('once', '1 times'):gsub('twice', '2 times'):gsub('%-removed', ' removed') ...

i have the following table entries: husband's great (09x) grandaunt great (11x) grandaunt ½ great (04x) granduncle I want to change them to: husband's (09x) great-grandaunt (11x) great-grandaunt ½ (04x) great-granduncle husband's great grandaunt >> I would expect this entry would be ignored or rpl t...

having used blank a great deal between commas, it will show <blank> when the first field is ''. If you put an actual blank in there, it will show as all the others.

where you do your king william, va and change it to king william, virginia and it already exists it means that you can merge them. one way -- still laborious, nevertheless is sorting by that column to get all the king william that occupy that column together, then it is click and ctrl click for each...

I have a plugin report that lists cemeteries and who is in them and mostly does what you want, but it requires a root *which you can make on the fly, and each burial or cremation record have a unique single source (you can have other sources on those records but they must contain that source on each...

I am at least surfactantly aware of those systems. for sanquine descendants, an integer can be used, but cosanginity in those systems (near as I can tell) require non-numeric or 'dot' extensions to map. I have tried by binary number the d'Aboville or Huntington, but it (as is) will duplicate numbers...

in ancestors the SOSA number is easy to create, and as a single number contains all sorts of information, and trivial to sort on. *****AND FAST TO COMPUTE***** Mike, if you recall this thread: https://www.fhug.org.uk/forum/viewtopic.php?f=42&t=16843&p=92875#p92787 I have searched or quite some time ...

perhaps you create your own standard thing in the note. Loc: grave U_14 Loc: lot 1554 section heaven Loc: section eternity, space 15 or something GLI: (grave location information for me) that is unlikely to show up in any other kind of note in that combination, and preface all locations with a stand...

I would like it to remain so, it will help considerably to know the number of indis, the number of fams, sources, places etc with a function, rather than counting them at plugins, for various reasons. fh knows it, and its calc-ed already, so should be as trivial as fhGetTag is to return any of those...

what I intend is to order and classify families\ PTG: 2 = fathers family SEQ starts at 0 3 = mothers family SEQ starts at 0 4 = descendants shared by mother and father SEQ starts at 0 5 = unlinked families and records. sequence SEQ starts at 0 (this is unfinished, and not of concern at this time, it...

Mike, in a post not shown up yet, after staring at that piece of scrap since 5:30, this morning, it came to me just after I posted it. change after change left that end out of place. here it is fixed up (I have simplified my '_STD_SLT':sltROT() logic written long ago, when I couldn't program any bet...

after staring at this since 5:30 this morning trying to figure it out all of a sudden I see an end out of place. thanks for looking.

simple selection code if you have a file root, and at record selection window, you press cancel it will ask you if you want to use the file root if you press Cancel Button on the do you want to use the file root screen, it returns cancel to the program if you press Enter button it sets up global poi...

I don't know what the underlying code is, but the callbuiltinfunctions are always heavy lifting. getting the pool is not trivial in cpu, memory, and time, and that gives me a inchoate structure, but a starting point. I would still have to inspect every individual record to determine some structure i...

on my way to organizing families in descendant order, I have: from a chosen root (can be file root) find oldest ancestor for father and mother of that root. we will call these seeds. find the families by descension. that will get near everyone in the file. we come to a few families left over, these ...

Mike, it works, thank you. I am astounded. The reason that I use inserts in the #, # + 1 way is that they are lightning faster than table.insert and this is a subprogram of a really intense program anyway. in either case, you provided, I would not have come to that on my own. the statement has a fam...