*Name Problems

Writing and using plugins for Version 5 and above.
Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Name Problems

Postby Ron Melby » 10 Apr 2018 17:46

local ptrINDI = fhNewItemPtr()
ptrINDI:MoveToFirstRecord("INDI")

while ptrINDI:IsNotNull() do
ptrNew = fhGetItemPtr(ptrINDI,"INDI.NAME:SURNAME")
Surname = fhGetValueAsText(ptrNew)
ptrNew = fhGetItemPtr(ptrINDI,"INDI.NAME:GIVEN_ALL")
Givenname = fhGetValueAsText(ptrNew)

ptrINDI contains: individual: Mavis Elaine Aune
Givenname contains: Mavis Elaine /Aune/
Surname contains: Mavis Elaine /Aune/
ptrINDI contains: name: Mavis Elaine Aune

I would expect Surname to be: Aune
and Givenname to be: Mavis Elaine

what am I missing here?
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 10 Apr 2018 18:38

Hi Ron.

fhGetItemPtr(...) gets a pointer to a Field regardless of Qualifiers.

A Field is separated from its Qualifier by a colon (:).
So INDI.NAME is the Field and SURNAME or GIVEN_ALL is the Qualifier.
See Knowledge Base > Understanding Data References.

Instead you need to use fhGetItemText(...) that supports Qualifiers.
See Tools > Plugins > How to Write Plugins > Sample Plugin Scripts > List All Individuals using all possible Surnames that uses that function with the same Qualifiers that you are using.
i.e.
while ptrINDI:IsNotNull() do
Surname = fhGetItemText(ptrINDI,"~.NAME:SURNAME")
Givenname = fhGetItemText(ptrINDI,"~.NAME:GIVEN_ALL")
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 10 Apr 2018 19:11

ahhhhhhhhhh. thanks, still learning and stumbling on nuance. nuancedly, of course.
Win 7 64 bit. FH V.6.2.6

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 14 Apr 2018 16:51

two problems:

-- Get INDI Record
ptrRecord:MoveToRecordItem(ptr)
ptrWork:MoveToRecordItem(ptr)
Surname = fhGetItemText(ptrWork,"~.NAME:SURNAME")
Givenname = fhGetItemText(ptrWork,"~.NAME:GIVEN_ALL")
Sortname = (Surname.. ", "..Givenname)
table.insert(tblINDI, Sortname)

on debug:
Surname contains ELLS
Givenname contains Ida Josephine
Sortname contains ELLS, Ida Josephine
but when I output the results this field is blank

ah, text, not item.

-- FaG Link

table.insert(tblSource,ptr:Clone()) **
ptrWork:MoveTo(ptr,'~.PAGE')
table.insert(tblPAGE,ptrWork:Clone())
** on this one, the 1st occurance of the output points to the source record itself, all subsequent output points to the INDI record and the citation line in it. (the first record is not at all different from the rest)

now, only one left...

-- FaG CEM
ptrWork:MoveToParentItem(ptr)
table.insert(tblCEM,ptrWork:Clone()) <<<<<<<<<here I want to get the BURI or CREM ADDR (or make it blank) instead of the Buried Mar 11865 in (PLAC...) record
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 14 Apr 2018 17:40

Presumably the first script ending "ah, text, not item." is NOT a problem (so why post it?).

The two problems are "-- FaG Link" and "-- FaG CEM" but there is not enough script to understand where ptr comes from and how it changes in each loop (I presume it is in a loop?).
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 14 Apr 2018 20:04

Code: Select all

@title: Cemetery Table FaG
@author: Ron Melby
@lastupdated: Apr 2018
@version: 1.0
@description:
FaG
* INDI
* EVENT
* CEMETERY
* SOURCE
* Page
* Plot

]]

-- SearchINDI
function SearchINDI(SrcTag, ptrSOUR)
-- SrcTag:    Tag of Item being searched for
-- action:    function to perform
-- Loop through Record Types
  local ptr          = fhNewItemPtr()
  local recordPtr    = fhNewItemPtr()
 
 ptr:MoveToFirstRecord('INDI')
  while ptr:IsNotNull() do
    if fhGetTag(ptr) == SrcTag then
      BuildTables(ptr, ptrSOUR)
    end
    recordPtr:MoveToRecordItem(ptr)
    ptr:MoveNextSpecial()
 end
end

-- BuildTables
function BuildTables(ptr, ptrSOUR)
  local ptrINDI   = fhNewItemPtr()
  local ptrLink   = fhNewItemPtr()
  local ptrWork   = fhNewItemPtr()
  local ptrCEM    = fhNewItemPtr()
  ptrLink         = fhGetValueAsLink(ptr)
  local Surname   = ' '
  local Givenname = ' '
  Sortname        = ' '
  if ptrLink:IsSame(ptrSOUR) then
  -- Matching Record Found Add to Tables.
 
  -- Get INDI Record
    ptrINDI:MoveToRecordItem(ptr)
    ptrWork:MoveToRecordItem(ptr)
    Surname = fhGetItemText(ptrWork,"~.NAME:SURNAME")
    Givenname = fhGetItemText(ptrWork,"~.NAME:GIVEN_ALL")
    Sortname = (Surname.. ", "..Givenname)
    table.insert(tblINDI, Sortname)

  -- FaG CEM
    ptrWork:MoveToParentItem(ptr)
    table.insert(tblEvent,fhGetTag(ptrWork))
    CemAddr = ('~.' ..(fhGetTag(ptrWork)).. '.ADDR')
    ptrWork:MoveTo(ptrINDI,CemAddr)
    table.insert(tblCEM,ptrWork:Clone())   --this line fix

  -- FaG Link
    table.insert(tblSOUR,ptr:Clone())
    ptrWork:MoveTo(ptr,'~.PAGE')
  -- <a href="https://www.w3schools.com/html/">Visit our HTML tutorial</a>
    table.insert(tblPAGE,ptrWork:Clone())
 
  -- Plot
    ptrWork:MoveTo(ptr,'~.NOTE2')
    table.insert(tblPlot,ptrWork:Clone())
  end
end

-- Main Code
-- Create Tables for Result Set
tblINDI   = {}
tblEvent  = {}
tblCEM    = {}
tblSOUR   = {}
tblPAGE   = {}
tblPlot   = {}

-- Prompt for Source
tblSOUR = fhPromptUserForRecordSel('SOUR',1)
if #tblSOUR == 0 then
  fhMessageBox('Plugin Cancelled')
  return
end
--if citation not used
local iCitations = fhCallBuiltInFunction('LinksTo',tblSOUR[1])
if iCitations == 0 then
  fhMessageBox('No Citations Found')
  return
end

SearchINDI('SOUR', tblSOUR[1])
if #tblINDI > 0 then
-- Output Tables built to Results Window
  fhOutputResultSetColumn("Person",   "text", tblINDI,  #tblINDI, 128, "align_left")
  fhOutputResultSetColumn("Event",    "text", tblEvent, #tblCEM,   40, "align_left")
  fhOutputResultSetColumn("Cemetery", "item", tblCEM,   #tblCEM,  256, "align_left")
  fhOutputResultSetColumn("Cite",     "item", tblSOUR,  #tblINDI,  56, "align_left")
  fhOutputResultSetColumn("Page",     "item", tblPAGE,  #tblPAGE, 156, "align_left")
  fhOutputResultSetColumn("Plot",     "item", tblPlot,  #tblPlot, 248, "align_left")
else
  fhMessageBox('No Citations Found')
end


1) first problem, is now partially known, but unsolved....I am saving the selected source in tblSource as a parameter, first cycle, but am confused where I should put it, only since I am learning a new language.
2) how do I set my formatted name as a link so it acts just like the individual Records window?
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 14 Apr 2018 21:13

-- FaG Link problem.
You are using tblSOUR for two purposes that conflict.
tblSOUR = fhPromptUserForRecordSel('SOUR',1) creates tblSOUR[1]
table.insert(tblSOUR,ptr:Clone()) is inserting tblSOUR[2], tblSOUR[3], et seq.
So 1st entry in Result Set comes from tblSOUR = fhPromptUserForRecordSel('SOUR',1)
You must use two different variables for the Source selection and the Result Set.
So use tblSel instead of tblSOUR for the Source selection script.

-- FaG CEM problem
ptrWork:MoveToParentItem(ptr) the parent of a Source Citation can be many, many items not just Events
table.insert(tblEvent,fhGetTag(ptrWork))
CemAddr = ('~.' ..(fhGetTag(ptrWork)).. '.ADDR') so if it is not an Event it won't have an ADDR field

how do I set my formatted name as a link
You need a buddy item entry in the Result Set for the Individual record pointer.
e.g.
tblNAME = {} for your formatted name
tblINDI = {} for the record pointer
Then in -- Get INDI Record
table.insert(tblNAME, Sortname)
table.insert(tblINDI, ptrINDI:Clone())

The Result Set then needs to use a buddy item:
fhOutputResultSetColumn("Person", "text", tblNAME, #tblINDI, 128, "align_left")
fhOutputResultSetColumn("Person", "item", tblINDI, #tblINDI, 128, "align_left", 0, true, "default", "buddy")

This is the Plugin equivalent of the Query feature in Knowledge Base > Sort Fact Query on Owner Surname and is an advanced technique.
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 15 Apr 2018 00:33

I guess I see that. thanks. I sort of thought I might be able to fhGetValueAsLink, fhSetValueAslink, because under the covers, they have to be a pair of pointers (a dictionary, or table entry LOL) like any other symbolic link is under the covers. Just seems more straightforward and efficient to me, buddy fields (do they have them in iup (hidden key fields?) are useful on a screen.

next issue, so I am cutting the name stuff down to surname_first but there is n cute way to get suffix (I store jr. sr. and such in suffix:SUFX) and it would be handy to show that as:
Sibley Fredrick Jr. in my name field. you got a slick routine to pick that out??
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 15 Apr 2018 10:29

I have started a new thread PDF Reports (15851) regarding the PDF stuff.

The Name Suffix field has the tag NSFX not SUFX so the script needed is:

Surname = fhGetItemText(ptrWork,"~.NAME:SURNAME")
Givenname = fhGetItemText(ptrWork,"~.NAME:GIVEN_ALL")
NameSuffix = fhGetItemText(ptrWork,"~.NAME.NSFX")
if NameSuffix ~= "" then NameSuffix = ", "..NameSuffix end
Sortname = Surname.. ", "..Givenname..NameSuffix

The If NameSuffix ~= "" then is needed to ensure trailing ", " is avoided when no Name Suffix.
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 16 Apr 2018 15:29

I did it so its:

Surname, Given All Sr.
and avoided the problem altogether.

also did the buddy field, not a big thing, like 4 lines or so inserted.

I have spent countless months on my PLAC and ADDR fields, standardizing, and on every new thing I come up with, I still find mistakes (albiet very small) so I have the situation where in certain CREM and BURI there is no ADDR so in that case I need to go to the parent CREM or BURI and get its note as a clone and stick in the table. seems like that will be easy.
Win 7 64 bit. FH V.6.2.6

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 18 Apr 2018 01:58

CemAddr = ('~.' ..(fhGetTag(ptrWork)).. '.ADDR')
ptrWork:MoveTo(ptrINDI, CemAddr)
if ptrWork == nil then
CemAddr = ('~.' ..(fhGetTag(ptrWork)).. '.NOTE')
ptrWork:MoveTo(ptrINDI, CemAddr)
end
table.insert(tblCEM, ptrWork:Clone()) --this line fix

in the debugger ptrWork is (null)
how do I compare a pointer to (null) ? it is not executing the statement between if and end
Win 7 64 bit. FH V.6.2.6

User avatar
David2416
Famous
Posts: 111
Joined: 12 Nov 2017 16:37
Family Historian: V6.2

Re: Name Problems

Postby David2416 » 18 Apr 2018 06:08

Use IsNull()
Eg
while ptrWork:IsNull() do
code
End

Null is a special value comparison to which always produces Null. It's not 0, nil, or an empty string.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 00:20

no Idea how I duplicated it, but I have a very cramped keyboard.
Last edited by Ron Melby on 24 Apr 2018 00:23, edited 1 time in total.
Win 7 64 bit. FH V.6.2.6

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 00:22

I try to be meticulous and accurate when entering information into my gedcom, nevertheless I am riddled with small errors.

as a sideline to my FaG Cemetery Table (all other situations have been worked out by your help) I am doing a cut down report to search for one type of error:

In the ~.SOUR.PAGE field I have:
http://www.findagrave.com/memorial/86624711
http://www.findagrave.com/memorial/104727644
...

So, I am a long way from understanding the match or sub psuedo-regex patterns..

I want to endup with the digits only, ie
86624711

is it ([^%d]} for the match?

and given that I am asking that question, what I would really like in the table is the pairs or trips or whatever, in the form, name and number that are duplicates only, but that is beyond me, of the 1200 or so records I have that have a findagrave there are perhaps (oh, I hope) maybe 12 that I have messed up on. but even to sort them (I can do that) I think I can stare and compare most of the errors.
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 24 Apr 2018 09:59

Yes, it does take a while to understand Lua Patterns, especially if not familiar with Regular Expressions.
The pattern "([^%d])" will match a single non-digit character.
Whereas "([^%d]+)" will match a series of non-digit characters.
But it is actually the digits that you want to capture and discard the rest of the URL, but keep anything else.
e.g.
local strOldPage = fhGetItemText(ptrWork,"~.SOUR.PAGE")
local strNewPage = strOldPage:gsub("http.-(%d+)","%1")

So that matches any text starting with http and ending with some digits %d+ that are captured.
Thus the whole URL is replaced by the 1st capture %1 of just the digits.
Any other text in the PAGE field is retained.
If there are multiple http then each one is reduced to just the digits.
If nothing matches the pattern then everything is retained.
So testing if strOldPage == strNewPage then determines whether anything changed.

In your last question, I guess you are just looking for duplicated grave numbers?
So the following script will detect the duplications assuming only one per PAGE field.
The strategy is to populate a table with an index entry for each new grave number.
So if the index entry already exists you have found a duplicate.
local tblGrave = {}

then inside loop
local strGrave = strNewPage:match("%d+")
if tblGrave[strGrave] then

~ duplicate found so create Result Set entry for strGrave No, with ptrINDI from tblGrave[strGrave], and current loop ptrINDI ~
else
tblGrave[strGrave] = ptrINDI:Clone()
end
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 11:12

well I've worked on this for quite some time....and dont know anymore than I did at the outset.

-- FaG Web Page
1. ptrWork:MoveTo(ptr,'~.PAGE')
2. table.insert(tblPAGE,ptrWork:Clone())
3. local strOldPage = fhGetDisplayText(ptrWork,'min')
4. local strNewPage = strOldPage:gsub("www.-(%d+)","%1")
5. table.insert(tblNUM,strOldPage)

I have tried line 3 both ways (fhGetItemText and fhGetDisplayText) (exactly as you have given it to me tatewise): with the following exception
local strOldPage = fhGetItemText(ptrWork,"~.SOUR.PAGE")
local strNewPage = strOldPage:gsub("www.-(%d+)","%1")

@ 5, ptrWork contains: where within source: http://www.findagrave.com/memorial/123456789 (I have stripped all http, https and trailing strings after the numbers on all FaG pages. WYSIWYG). both local str(s) contain "". and the output is on the order of:
ELLS, Josephine (c1) and bbbbbbbbb (c2) Ihave tblPAGE as buddy, so clicking on the blank field gets me to the BURI or CREM record but not the page (the record parent is in blue when I go there) (because of this strange behavior, I know something is wrong with the table and of course I can see it)

I know ptrWork is correct, and it is the situation either way fhGetDisplay or fhGetItem... no errors, and I cant see for the life of me how this code is incorrect, but obviously it is '
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 24 Apr 2018 11:40

It is important to keep a clear understanding of what ptrWork is pointing at.

The main problem with line 3 is that it is missing a parameter and should be:
local strOldPage = fhGetDisplayText(ptrWork, "~.", 'min')

but since ptrWork is pointing at the PAGE field, you can more simply use:
local strOldPage = fhGetValueAsText(ptrWork)
or
local strOldPage = fhGetItemText(ptrWork,"~.")

but NOT:
local strOldPage = fhGetItemText(ptrWork,"~.SOUR.PAGE")
Can you tell me why that won't work?
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 11:46

it would end up looking for something like
'~.SOUR.PAGE' (base)
'~.SOUR.PAGE' (offset) so...

'~.SOUR.PAGE~.SOUR.PAGE'
Win 7 64 bit. FH V.6.2.6

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 11:59

local strOldPage = fhGetValueAsText(ptrWork)
this worked, looking at it I see why, but still a little shaky on why the old code didnt.
I also needed to write strNewPage on line 5.

This is going to help with the stare and compare, found 2 more on a quick run thru

And earlier you had some code that would kind of work, but ..

it would need to work more like this. if I put out this table sorted by my number
read a record, hold it, compare to next record, if dups, write hold record and current record to table, if not do not write, new record becomes hold record
until eof.
output dup table.
Last edited by Ron Melby on 24 Apr 2018 12:15, edited 1 time in total.
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 24 Apr 2018 12:14

OK, all good replies.

Regarding the original fhGetDisplayText(ptrWork,'min') and why it does not work, consider the API function syntax:

strText = fhGetDisplayText(ptr[, strDataReference [, strDisplayOption]])

Parameter 1 is ptr which in your case is the ptrWork pointer

Parameter 2 & 3 are shown in [square brackets] so are optional, but strDataReference must exist if you wish to use the optional strDisplayOption
In your case you had 'min' as the Parameter 2 strDataReference which is clearly wrong.
In my example I used "~." as the Parameter 2 strDataReference which does not adjust the ptrWork pointer.
Then 'min' is the Parameter 3 strDisplayOption to avoid the label.

BTW:
Use my local tblGrave = {} technique to avoid having to stare and compare. It caters for replications anywhere.
Your suggestion does not work unless the duplications are in adjacent Individual records, and does not find triples.
The Result Set can easily be sorted by grave number either in the fhOutputResultSetColumn(..) function or by hand afterwards.
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 12:32

that bit I understand, though the doc is a little murky, but I didnt code that one, just used a simpler one. it is apparent that parameters are positional, but I never thought to use a kinked parm in that I thought it would throw the pointer out into the ozone. In most of my coding career, if you did that to a pointer it would not stay in a valid place but could be anywhere.


I am having some problem understanding where the pointer sits, at times. obvs.

so in your experience, would a 1 element table with table.insert and table.remove or oldstring newstring variables be faster and less intensive to compare two records to decide whether to write both or throw away the older?
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 24 Apr 2018 13:00

I know you ended up using a simpler function.
The important point is that your original fhGetDisplayText(...) attempt would have worked if it had all 3 parameters, but your code omitted the 2nd parameter, and should have been fhGetDisplayText(ptrWork, "~.", 'min') which works OK.
The data reference "~." is a technique you need to make a note of because it does not move the pointer.
The kinked tilde ~ in Plugin scripts means move the pointer according to what follows, but if what follows is dot . then no move is specified, so the pointer stays put.

Use the local tblGrave = {} technique as I explained, as it is very efficient.
Do NOT use table.insert or table.remove
Whenever the script finds a Grave Number in strNewPage then first see if tblGrave[strNewPage] exists.
if tblGrave[strNewPage] then i.e. Has the Grave Number been added to the table already?
If it already exists, then a duplicate has been found and a Result Set entry is needed as follows:
1st column will be the Grave Number in strNewPage
2nd column will be the Individual pointer in tblGrave[strNewPage] where Grave Number was first found
3rd column will be current Individual pointer ptrINDI

Alternatively, if tblGrave[strNewPage] doe NOT exist then this is the first time that Grave Number has been found.
So use tblGrave[strNewPage] = ptrINDI:Clone() to create the table entry for that Grave Number and save the associated Individual pointer in that entry to be retrieved later if a duplicate is found.
Mike Tate ~ researching the Tate and Scott family history.

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 15:13

ok. perhaps I am not understanding, for simplifed discussion I have:

Al 1
ben 2
fred 2
josh 2
ralph 3
ed 4

my resultant table needs to be:

ben 2
fred 2
josh 2

since they are the duplicates, and in most cases related, and one of them will on FaG contain links to the others.

additional item has cropped up.

I have a right justified field next to a left justified field and they ----blur----
so, if my reading is correct, i would have to make a dummy table containg say 2 spaces, so I can visually divide them.

for example
tbl1........tbl2
118124 www.findagrave.com/memorial/118124
would become
tbl1....tbl2..tbl3
118124.....www.findagrave.com/memorial/118124
I dont think print will work here, so ......

is that what needs doing?
Meh that wont work either tbl2 is a buddy field of tbl1
how can I get two spaces in there?
ehhhhhhhhhhhhhhhhhh, nevermind, add it to the end of each tbl1 entry
Win 7 64 bit. FH V.6.2.6

Ron Melby
Famous
Posts: 178
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Name Problems

Postby Ron Melby » 24 Apr 2018 17:10

I am trying to solve for the general case:

findagrave entries can have for example
:

http://www.findagrave.com/memorial/123456789/al-edwards
https://www.findagrave.com/memorial/123 ... al-edwards
www.findagrave.com/memorial/123456789/al-edwards
www.findagrave.com/memorial/123456789/
www.findagrave.com/memorial/123456789

or various and sundry other combinations due to inaccurate or inconsistant editing.

this pattern:

local strMemorial = strWebPage:gsub(".-(%d+).-","%1")
seems to work at the front garbage, but does not clip any trailing garbage.
so, how should I pattern... ignore any leading garbage (get numbers only) ignore any trailing garbage that may exist
Win 7 64 bit. FH V.6.2.6

User avatar
tatewise
Megastar
Posts: 14833
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Name Problems

Postby tatewise » 24 Apr 2018 19:33

I assume you want to remove everything after the Grave Number even if there is extra text after the URL.
strOldPage:gsub(".+findagrave.+/(%d+).*","%1")
will work as explained below:
.+ will match longest text preceding findagrave
findagrave will obviously match findagrave
.+/ will match longest text following findagrave ending in / followed by digits
(%d+) will capture longest string of digits
.* will match anything after the digits including nothing
I include something unique like findagrave in the pattern to ensure no other digits in a PAGE field will match by accident.
e.g. ".+(%d+).*" will match Page 23 that I suspect you don't want.

Regarding the duplicates and using your example, eventually tblGrave will contain:
tblGrave[1] holds ptr to Al
tblGrave[2] holds ptr to ben
tblGrave[3] holds ptr to ralph
tblGrave[4] holds ptr to ed

So when fred yields Grave Number 2 then it discovers tblGrave[2] holds ptr to ben.
In my scheme the Result Set would list the duplicates in pairs:
2 ben fred
2 ben josh
That gives the same information as your suggested list, and since it is for a once-off fix does the format matter that much?

Now let's look at the right/left justified fields.
I don't understand why column tbl2 displays anything, as it is a Buddy column that is hidden by tbl1.
Anyway, why not use a different column order, or use align_mid, or append 2 spaces to tbl1 contents.
e.g. table.insert(tbl1,strNumber.." ")
Mike Tate ~ researching the Tate and Scott family history.


Return to “Plugin Discussions”

Who is online

Users browsing this forum: Bing [Bot] and 12 guests