* All in the Family

For users to report plugin bugs and request plugin enhancements; and for authors to test new/new versions of plugins, and to discuss plugin development (in the Programming Technicalities sub-forum). If you want advice on choosing or using a plugin, please ask in General Usage or an appropriate sub-forum.
Post Reply
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

All in the Family

Post by Ron Melby »

I have set up a test. I expect the number 3

1 ADOP
2 NOTE by the Nelson C. Pike family of MN (likely after her parents divorce, as Edna had no money to raise her)
2 FAMC @F1796@
3 ADOP BOTH
1 ADOP
2 FAMC @F229@
3 ADOP BOTH
1 FAMC @F229@
1 FAMC @F37@
1 ADOP
2 FAMC @F347@
3 ADOP HUSB
1 FAMC @F347@
1 FAMC @F132@
2 PEDI Foster
1 FAMC @F722@
2 PEDI Step
1 FAMS @F5@
1 FAMS @F63@


this works.
ptrADP:MoveTo(iptr,'~.ADOP') -- works
adop = rtvElemCount(ptrADP) -- (3)

this does not
ptrADP:MoveTo(iptr,'~.ADOP.FAMC')
adop = rtvElemCount(ptrADP) -- (1)

I am trying to find all ADOP FAMC while retaining the FAMC pointer most efficient manner
I am trying to find all PEDI FAMC while retaining the FAMC pointer most efficient manner ( I must also read the PEDI text)

Not having much luck without really spaghetti code, that doesnt quite work...LOL

here is rtvElemCount which should be fine.
function rtvElemCount(eptr) -- Count instances of TAG
local thisPTR = eptr:Clone()

local elem = 0

while thisPTR:IsNotNull() do
elem = elem + 1
thisPTR:MoveNext('SAME_TAG')
end
return elem
end -- fn rtvElemCount
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

rtvElemCount counts instances of SAME_TAG within parent tag.
So it finds 3 instances of 1 ADOP within record.
But will only find 1 instance of 2 FAMC within first ADOP parent.

You have to loop through 1 ADOP instances within record.
Then for each one count any instance of 2 FAMC.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

I knew I was logically asking for:
(iptr,'~.ADOP[?].FAMC[?]')

but the plan was to do just as you describe, I just thought you might have a slick all in one way to do it.
LOL.
FH V.6.2.7 Win 10 64 bit
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

not yet handy with the idiom.

Code: Select all

function rtvFAMPtr(iptr)
  local thisPTR = iptr:Clone()
  local fptr    = fhNewItemPtr()  -- ALL FAMC
  local cptr    = fhNewItemPtr()  -- space pointer
  local aptr    = fhNewItemPtr()  -- ADOP
  local pptr    = fhNewItemPtr()  -- PEDI

  fptr = fhGetItemPtr(thisPTR,'~.FAMC')
  if fptr:IsNull() then
    return fptr
  end

  local fc = rtvElemCount(fptr) 
  if fc > 1 then
    while fptr:IsNotNull() do 
      pedi = fhGetItemText(fptr, '~.PEDI')
      if pedi == '' 
      or pedi == 'Birth' 
      or pedi == 'Illegitimate' then
        table.insert(ftbl, fptr:Clone())
      end
      fptr:MoveNext('SAME_TAG') 
    end

    cptr = fhGetItemPtr(thisPTR,'~.ADOP')
    local ac = rtvElemCount(cptr) 
    if ac > 0 then
      while cptr:IsNotNull() do
        aptr = fhGetItemPtr(cptr, '~.FAMC')
        if aptr:IsNotNull() then 
          -- rmv from ftbl
          for _, v in pairs(ftbl) do
            if aptr:isSame(v) then
              v = nil      
            end
          end
        end  
        cptr:MoveNext('SAME_TAG') 
      end

      assert(#ftbl == 1, fhGetRecordId(iptr))
      fptr = ftbl[1]
    end
  end  
  return fptr
end
this uses the test data provided earlier

in the first loop if FAMC > 1
I read the FAMCS with no PEDI or certain PEDIs into ftbl as pointers (this works correctly, of the 5 data have 3 inserted into the table.

in the second loop I get adoption famcs, it works correctly getting 3 of them

I then try to compare the adop famc to the 'raw' famc in the table when I find it winnow it from the table, hopefully getting down to one (I hope birth) family.

running thru debug, it loops correctly but does not find the clear (in my mind) matches.

I have tried several ways,
v
v.fptr
fptr[v]

*NB: while I fastidiously sort my records, and in my 'production' file it means the resultant 1st FAMC is the one I want, that cannot be a valid assumption for the world at large. So, anyone (LOL. Mike) who sees the problem or the elegant solution, help?

but cant seem to get the right combination. the logic seems sound so it must be
FH V.6.2.7 Win 10 64 bit
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

I see equivalent pointers that are not set to nil.

they walk right right around the if, how can that possibly be true?
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

Maybe you are mixing up nil and null again?
nil is an Lua value representing 'nothing' and is treated as false
null is an FH ptr (fhNewItemPtr) that is pointing nowhere and where ptr:IsNull() == true

ptr = fhNewItemPtr() sets ptr to null
ptr = nil sets ptr to nil

If a ptr:IsNotNull() then in the debug pane lower right it shows what it is pointing at.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

my understanding is that if I set the value to nil, it no longer exists, if I set it to null, it is rather like a '' (empty).

its the reason I use pairs instead of ipairs.

for k, v in pairs.

k,v is:

1, ptr
2, ptr
3, ptr

so:
if I do the following:
setnull
I have
1, ptr
2, null
3, null


if I do the following:
nil
I have
1, ptr
2, nil
3, ptr
and then it becomes
1, ptr
2, ptr

the old 2 is invisible to the program
isnt that the standard way to remove entries from a table?

in any case, the problem hasnt progressed to that point
nil.png
.

it doesnt go inside the if on this.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

What to you think aptr is pointing to?

What do you think v is pointing to?

Why do you think they should ever be the same?

The clue to the answer is clearly given in the debug pane.

I suspect you think they are pointing to the Family record of ...Gordon Andrew CARLSTROM and Neva Elaine POTTER.
But NO.
They are pointing to two different FAMC tags that happen to Link to Family record above.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

I do think they are pointing to the link to family record of gordy and neva

I read all the FAMCs.

I then look for those that are prefaced by adoptions

1 ADOP
2 NOTE by the Nelson C. Pike family of MN (likely after her parents divorce, as Edna had no money to raise her)
2 FAMC @F1796@
3 ADOP BOTH
1 ADOP
2 FAMC @F229@
3 ADOP BOTH
1 ADOP
2 FAMC @F347@
3 ADOP HUSB
1 NCHI 2
1 FAMC @F229@
1 FAMC @F37@
1 FAMC @F347@
1 FAMC @F132@
2 PEDI Foster
1 FAMC @F722@

thats whats on the cart in INDI 78

I do not understand where else the tags could be coming from that they are not pointing at the same family.
gordy and neva are 229.
obviously, reading the INDI.FAMC tags I am reading the one that is 2nd (after the NCHI) then when I read the ADOP.FAMC I am reading the one right after Nelson C. Pike. I say they are pointing to the same thing, and therefore equivalent. I am obviously wrong, and you are obviously right, prima facie by the turn of real world events. So, my issue is very clear.... I have a table of FAMC tags. How do I determine which ones are ADOP since never the twain shall meet? I cant test them for :IsSame nor ==
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

You are missing the point(er) :D

They are pointing directly to the %INDI.ADOP.FAMC% and %INDI.FAMC% tags respectively.
That is why they are shown as Link to Family record (...Gordon Andrew CARLSTROM and Neva Elaine POTTER)

It is the links within those two tags that are pointing to the %FAM% records you want to compare.
They would be shown as Family: ...Gordon Andrew CARLSTROM and Neva Elaine POTTER

So you need to use local fama = fhGetValueAsLink(aptr) and local famv = fhGetValueAsLink(v)

This is really very basic primer stuff that you should understand by now :o
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

I should but I don't. I have some serious confusion over when is a "not pointer" not a pointer.

they don't act like pointers in some cases, in some cases they do.

and I think of the different tags etc as objects.

In my mind I was comparing the FAM object to the FAM object.

Sometimes I recognize my error, and sometimes I do not.

I'm working on it.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

A pointer is always a pointer, but you must always consider what it is pointing at.
Is it pointing at a FAMC tag or at a FAM tag?

The confusion is that a FAMC tag holds a pointer to the FAM tag.

You don't have a problem with a pointer to a DATE tag where it holds a Date value.

You just have to think a bit harder with a pointer to a FAMC (or FAMS) tag that holds a FAM pointer value.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

but a date is a date, it has properties

a famc or fams ultimately points to a FAM, its simply a matter of what side of the sheets you are on.

a famc is a fam
a fams is a fam

there are no famc record types
there are no fams record types

so ultimately i think of it (incorrectly) because there is a distinction without a difference here...

ptrFAM == fam29
ptrFAMC == fam29
ptrFAMS == fam29

ptra== ptrb ==ptrc
since they are all pointing to the same 'object'

in many respects the nonpointer-pointer FHfunctions surfactantly act like pointers. Gotta believe there are pointers behind them somehow nobody would write anything like an entire application system in LUA unless they were actually writing a bunch of c or c++ functions with an LUA front end.

I see how

ptrADOP `= FAMC
but a fAM = FAM

so, in time I will become used to the artifice. I promise.

as it is, thank you for your help, once you pointed me at it, I saw that I was pointing at spaces and not at objects....(I understand most people wont understand this unless they know IBM assembler languages.

LOL.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: All in the Family

Post by tatewise »

You will just have to come to terms with the truth that FAMC, FAMS and FAM are all very different objects.

Imagine you had a chained list where A points to B, B points to C, C points to D.
A, B, C & D are four different objects.
It is untrue to say that A = B = C = D just because by following the pointers you always end up at D.
Each of the four objects hold four different values.

Similarly FAMC points to FAM, and FAM.HUSB points to INDI.
It is a linked list with several different objects and each object holds a different value.
So a pointer to a FAMC object is NOT the same as a pointer to a FAM object.
The FAMC object holds a value that is a pointer to a FAM object.

That is all very traditional software linked list topology.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: All in the Family

Post by Ron Melby »

I have been giving this a bit of a think. The way you have described the situation, as linked list now makes sense to me. How long that will stay in my head is anyones guess.

Thanks for the explanation. Having gotten a so so base of function, the next phase is on. I will make a separate thread.
FH V.6.2.7 Win 10 64 bit
Post Reply