* Finding the index of the currently selected meta-field enumeration

[Gary_G]

Does an enumeration type meta-field have an attribute that represents the numeric index of the current selection in the defined selection list? If so; a brief example would be appreciated.

[tatewise]

No, it doesn't.

Let's assume you have a {Type} metafield with shortcut data ref %SOUR.~EN-TYPE% and text value Marriage.

The Source Template will have the following Enum related data ref fields:
%_SRCT.FDEF.NAME% with value Type
%_SRCT.FDEF.PROM% with value Birth | Marriage | Death | Divorce
That PROMpt field populates the droplist provided when entering the field value, but you are not restricted to that set and can enter any text value you wish. So it is really just like any Text field.

With the field value of Marriage it might be possible to determine that is the 2nd entry in the list.
However, a field value of Burial is perfectly legitimate where no numerical index is possible.

The FH Help explains Enum type fields thus:

The Enum type is similar to the Text type, in that any text can be typed into an Enum field. The difference is that an Enum field has a little black triangle at its right side. If the user clicks on this, they will be shown a convenient list of commonly-used possible values for the field, which they can select from. Suppose, for example, that a field is needed to store a country name. The dropdown list could contain a list of commonly-used country names, but the user could also type in the country name, if the one they needed wasn't in the list. The list of possible values for the dropdown list, is specified in the Prompt field.

[Gary_G]

"tatewise"

Thank you for explaining. Based on exploring the SQL Query scenes, I'd come to a similar conclusion, but wanted to check with a more experienced user.

It seems, then, that there is currently no way to create logic to relate an entry in one enumerated list to the corresponding entry in another.

I'm going to risk trying to capture my impressions, below. I'd appreciate knowing your opinion on whether I'm essentially on the right track in developing a high-level view of how FH7 works. It might avoid some future questions on my part.

I'm starting to get the feeling that FH7 works with a huge XML file and the that the data-accesses logic is hardcoded into the FH7 program itself. If that logic does not have a particular data-access function, then there's not much one can do short of trying combinations of the existing "public" functions. Now; I there may be some way to augment FH7 via its associated plugin language, but I'm not yet familiar with the language and not really sure those would help in a data-entry template case.

All this could explain why I've been looking in the manual and not actually finding what I needed to wrap my head around how FH7 data-access works. The manual appears to concentrate on defining the library of "public" functions by which a user can access the data structure, but does not really speak to the data structure itself. That is likely because the structure appears to be fluid and, within certain limits, varies based upon the data entered. From what I've seen, one is only able to see the currently defined structural elements by exploring the screens used in creating a Query.

If the above is largely a correct assumption, I may consider making a request to Calico Pie to provide access to a function for determining the current "dynamic" enumeration set and index, because it seems reasonable that something like that may already be part of the "private" function library of the program. I've had to design and handle dynamic lists before, so I'm sure that the designer has made allowances for this in the currently "private" functions.

[NickWalker]

We don't actually know how the Family Historian database is coded. I would assume it is a bespoke relational database that Calico Pie have developed using various data structures as nodes with pointers/linked-lists to connect them all together. Effectively a graph or network data structure.

As you've suggested, they give access to some of that structure via data references, queries, etc. and further access via their LUA functions but not all of the structure is available. I'm sure it would be possible for them to make available parts which are not currently accessible but of course this would depend on their development priorities. I expect they've tried to second guess potential use cases when deciding which areas to expose to the public.

[Gary_G]

Thanks, Nick. I appreciate your confirming what I suspected.

Having been in software engineering prior to retirement, you can imagine that I would find the existing documentation a little bit "frustrating". That said; FH7 seems to be a good program and I'm happy to do my best to work within the limitations of what is available ... And, I suppose, I'm still finding out what those are.

Right now; I'm trying to build the framework of templates, queries etc. that I need to complete the porting of my "Lumper" data from RootsMagic to a FH7 "Splitter" one and to support my workflow. Once I've done that, I should be able to get back to a more research-related focus. So; in the meantime, I hope the group will forgive my asking so many seemingly random questions.

[tatewise]

Gary, as Nick says, FH uses its own memory-based data structures modelled on the GEDCOM data relationships.
It does not use SQL, XML, or any other file-based data structures. The FH data model is rigid not fluid.
Externally, it only uses the GEDCOM file, and the customisation files that are well documented.

The tools such as Queries and Plugins cannot adjust those memory-based data structure relationships.
They can only inspect them and populate them with data values, just like the user interface.

The data is mostly accessed via Data References (derived from GEDCOM structures) and help with composing them is provided through many Data References Assistants (DRA). The most popular DRA is the Query Columns tab Fields pane.

Regarding Source Template ENUM fields, as I tried to explain, they are NOT conventional Enum structures at all.
They are simple plain text fields that can hold absolutely any values which are not associated with an Enum list.
The droplist associated with the template ENUM field is simply a shortcut list of suggested values. So there is no concept of an enumeration set and index.

[Gary_G]

Thanks, "tatewise".

I understand the implications of what you and Nick said. I am still developing a picture of roughly how FH7 works, finding what's available to a user and where to look for more information, and also how to use that info. It's an iterative process and will take some time. It appears that not a lot is formally documented and one needs to discover a lot on ones own or rely on the help of more experienced users such as the both of you. So; I just wanted to say that your feedback and forbearance is sincerely appreciate.

[tatewise]

Gary, could you expand on "It appears that not a lot is formally documented" to explain in more detail what you believe is missing.

[Mark1834]

To be fair, none of the major apps document their internal plumbing.

RM is probably the most accessible, but all the documentation is reverse-engineered by enthusiasts who understand SQLite, not published by RM. FTM is almost certainly a relational database, but encrypted to prevent inspection. FH keeps its internal structure as proprietary IP, but makes extensive external “hooks” available.

IMO, that is a perfectly reasonable way of doing it.

[Gary_G]

"tatewise";

While this is likely not the place to go into documentation improvements, I can give you a very limited example.

The data is mostly accessed via Data References (derived from GEDCOM structures) and help with composing them is provided through many Data References Assistants (DRA). The most popular DRA is the Query Columns tab Fields pane.

While the functions are documented and some limited amount of "programming" is a recognized feature of FH7, a user really has little guidance on where to find a list of valid data names for use in the functions. Until the above was stated in one of the preceding thread posts, I wasn't quite sure where to look to find them. So; it appears there are at least some areas in which the documentation, as related to developing templates, could be augmented.

[Gary_G]

Mark;

Let me be quite clear on this... I was not in any way expecting Calico Pie to disclose their propietary data structure.
However; having made specific functions available, there is an implicit obligation to state how to determine what are valid parameters or at least where to find them.

[tatewise]

Regarding documentation...

You mentioned topics such as functions, data names, and templates, which are advanced techniques and the documentation expects you to spend some time becoming familiar with the details.

In the Understanding Functions section of Help is the Data Types page which explains a Data Item parameter is a Data Reference.

In the Sources and Source Templates section of Help is the Source Template Formats page which under How to Use Data References or Functions within Formats it discusses Data References and refers to Understanding Data References.

The Understanding Data References Help page explains the details. It says FH will almost always help you construct them and towards the end specifically mentions Data Reference Assistants.

In most fields where Data References can be inserted, the user interface has an << Insert Data Ref... button or similar to compose the data structure. A glaring exception is adding Metafield Shortcut Data References to the Source Template Format expressions, but that is a very advanced feature.

So I maintain that the documentation is all available, but accept that you do sometimes have to search to find what you need.

[Gary_G]

"tatewise";

I would put it to you that templates themselves are not all that advanced a subject. They are so very similar to those in RootsMagic that the RootsMagic templates can be automatically converted and run well. I have absolutely no issues understanding and using templates themselves. What I would agree to is that using functions is a relatively advanced topic, because the design is unique to the proprietary features of Family Historian. Without some overarching writeup to set the tenor of how to approach them and/or someone to point out the relevant reference material to read, one will flounder.

I think your posting highlights the true issue that I have with the documentation. The elements may be all there, but they are so widely distributed amongst other topics. So; one almost needs someone such as yourself to point out where they are. Honestly; following the dearth of hyperlinks across the online documentation makes things difficult to follow by creating a "can't see the forest for the trees" situation. The overview you've just provided is likely the best synopsis/overview that I've seen so far. It points out some of the key documents to read and a direct link to where to find them. Perhaps; there is a need for something like a one or two page "Starting with Function Guide" to do much as you have attempted to do. I want you to know that I appreciate you taking the time to provide the noted synopsis.

[tatewise]

I tend to agree with you. The documentation mostly all exists but there is sometimes insufficient introduction to pull it together.
Possibly FH suffers from the legacy of its evolution in its user interface and help structure that needs a major overhaul.