Easiest explained with an example:
// Record Two. TRecord2 = record // An exciting value. a: integer; end; // Record One. TRecord1 = record // The record2. Two: TRecord2; // Must be @true if @link(Two.a) is bigger than @code(10). x: boolean; end;
The pasdoc parser complains that it can't understand the link "Two.a":
Warning[1]: Could not resolve link "Two.a" (from description of "pasdocrecordtest.TRecord1.x")
It seems pasdoc can only identify fields of top-level records by name, not fields of nested records. This is a shame, as it means you have to refer to nested fields by their parent types, which is much less clear for the end-user. Hopefully it would not be too hard to add the ability to follow chains of nested records by their field names.
The
@link
should lead to@link(TRecord2.a)
, not@link(Two.a)
.In order to link to
TRecord2.a
but show it asTwo.a
, you can write@link(TRecord2.a Two.a)
, see https://github.com/pasdoc/pasdoc/wiki/LinkTag .That said, indeed it isn't working with the nested record as it should. I'm attaching a testcase I made, based on your code, and indeed it uncovers two situations that don't work as they should. The problem is most likely in PasDoc's
TPasItem.FindNameWithinUnit
method -- it's way too simple :), it was never updated to understand nested structure types.I'll look into this when I'll find a bit time, that's probably next year :) Thanks for the report!
Since the link tag can link to fields, should it not also be able to link to fields of nested records (which are essentially fields of the parent record, but with a hierarchical name)? Only having to write the name of the field would make the documentation far easier to maintain.
I'd agree the two cases you've shown in your class testcase look like bugs.
I agree,
@link(Two.a)
should also work eventually :)