* Risks of using undocumented feature

[shoshk]

I am working on a plugin which manipulates rich text. Among other things, I need to retrieve record ids from the 'record link table'. Other than a reference to the 'record link table', CP does not seem to have documented anything regarding its implementation. After a bit of poking around, I've figured out the data references for the table and it looks like I can access the information with no problem.

Mike, it appears that you access the 'record link table' in your Where Used Record Links plugin.

I am concerned about using an undocumented feature.

Thoughts?

[ColeValleyGirl]

I've done similar undocumented stuff (parsed the fhf files, created queries programmatically) when there was no other way to achieve what I needed. It's always going to be a bit risk, as CP could modify things in a future release, but I suspect it's marginally less risky if it's data held in the Gedcom file...

[tatewise]

Actually, my Where Used Record Links plugin does not explicitly access the rich text record link tables.
It searches all data items using ptrItem:MoveNextSpecial() and checks if fhGetDataClass(ptrItem) == "link"

Then it uses the code snippet to BuildDataRef(ptrItem) which reveals the link table ...NOTE2._LINK_* tags, etc.
If FH did not want those record link table tags to be available in Plugins then they would be 'hidden' as has happened with other 'magic' tags.

Strictly speaking, the API is not presenting GEDCOM data but the FH view of its low level data structure.
For example, when it comes to Templated Source Citation Metafields the API demands you use Metafield Shortcuts and not direct access to the _FIELD & DATA tags. See Copy Child Branch Fields code snippet for FH V7 (18691).