Family Historian User Group

I'm trying to write a plugin to list all birth source citations in one long list, irrespective of whether it is a split or lumped source or the order the sources are listed (so something more akin to a traditional database retrieval). Where a birth has multiple sources, each would appear in the table as a separate row.

It's almost working, as I can list all the source titles without any problems. An outer loop cycles through INDI records, and an inner loop through their birth sources (~.BIRT.SOUR). I can get citation and text ok for split sources, but all the lumped sources (mostly GRO Indexes) are blank. The output is shown in the screen grab, and the part of the code that walks through the source and pulls out relevant details is shown below. Presumably, my Data References are not correct for the lumped sources, but they are the same as in a query that was pulling out the same data just for the GRO Indexes.

Is it a simple typo, or am I doing something fundamentally wrong?

That is fundamentally wrong.
ptrL refers to the Source record and thus '~.TEXT' is the Source record Text From Source field.
i.e. It is INDI.BIRT.SOUR>TEXT
There is no '~.PAGE' and '~.DATA.TEXT' tags in a Source record.

Lumped Sources don't use that field, but use the Citation's Text From Source field.
i.e. It is INDI.BIRTH.SOUR.TEXT
In this context there is no '~.TITL' or '~.PUBL' field.

So for lumped Sources you need to point to the INDI.BIRTH.SOUR field to access '~.PAGE' and '~.DATA.TEXT' that don't exist inside a Source record.

Thanks again Mike. I had these lines further up from the section I quoted (omitting lines relating to place, date, etc), so I changed ptrL to ptrS for the two terms relating to the lumped sources and it worked as expected.
I think the way I rationalise this in my head is that ptrS relates to the citation that supports the birth fact, and ptrL is the source record that the citation links to. Is that a reasonable paraphrasing in slight less technical terms? I should probably have called them ptrC and ptrS, respectively, as perhaps slightly more logical short names.

Yes, that is perfect paraphrasing

BTW: This is slightly more efficient and avoids temporary ptrP and the count:

table.insert( tblPUBL, fhGetValueAsText( fhGetItemPtr( ptrL, '~.PUBL' ) ) )

If you need to know how many entries in tblPUBL then use #tblPUBL

Mike, your second comment is interesting. The alternative code may be efficient, but it is opaque. 20 years ago, I did a company-sponsored programming course with the OU using the superb but now well outdated Borland C++ Builder (that was back in the days of Windows 2000, and it doesn’t run on anything later than XP). There, the mantra was definitely one of transparent and easy to read code, on the basis that code is written once but read many times, often by people other than the author. Perhaps they took it a bit far, as they frowned on common constructs like i++ and j += 5, but it’s a principle that I’ve tried to follow.

I’m still very much a Lua newbie, and I do find most store plugins that I’ve looked at very difficult to follow. That’s not getting at anyone in particular, as I remember comments on a different thread about how all three of the main plugin authors find it difficult to follow each other’s coding style. Could I put in a plea for a little more clarity and commenting, please, even if it’s at the expense of technical elegance. Ideally, all store plugins should be capable of being taken up by somebody else after the original author is no longer willing or able to support them.

We muddle through, with a combination of the KB, FH help, online manual, and various help and tutorial sites, and Lua doesn’t actually look that complicated, but it takes time...

It depends who you're talking about by opaque. Let me explain.

It is no more opaque than ptrS:MoveTo(ptrI, '~.BIRT.SOUR') unless the viewer understands the FH API and GEDCOM tags.

Before long you will discover the collection of standard Lua libraries that many Lua coders know inside out.

The string library is probably the most used with methods such as format, lower, upper, sub string, gsub find & replace, etc...
Many of those methods are next to impossible using plain Lua script.

The table library probably comes next with methods insert, remove, sort, etc...
Those methods avoid intricate & obscure code manipulating the table entries so are less opaque and more efficient.
They are well defined in the Lua reference manual the same as the FH API functions and methods.

Yes, the string library looks fairly straightforward, and I’ve got some interesting results from developing my basic template above that are relevant for FH7. I’ll post an update over the weekend when it’s finished.

A quick question before I finalise my draft script, please.

I can extract a date using something like datD = fhGetValueAsDate(ptrP), and display the date by extracting the first date point object with datptD1 = datD:GetDatePt1() (and optionally the second date point if it is a range). However, I'm struggling to get qualifiers such as "about", "before", "after", etc, to display in my table. The debugger tells me they are in the date point object, but how do I display them without converting the whole thing to plain text, which would make the column unsortable.

I can't find anything relevant in the forum or FH help files.

Mark,

Perhaps I'm missing something, but could you display the qualifier in a separate column.

Shosh

Thanks, that would certainly work ok and not affect the functionality, as date sorting seems to ignore qualifiers anyway, but I was hoping to do it in one neat column (as the records window does) rather than split over two. Perhaps that is not possible, as I've seen other examples where plugins and queries can't fully emulate the records window display.

The necessary Date methods are in the FH API under Date as GetType and GetSubtype where you found GetDatePt1.

Thanks Mike, but that doesn't seem to give me a single field containing a sortable full expressed date, as the Records Window does. To avoid the untidiness of splitting the qualifier and the value across separate columns, the approach I have taken is to have two columns, a fully sortable date that loses the qualifier, and a full but unsortable text version via string.sub(fhGetDisplayText(ptrP), 7).