pasdoc-main

[Pasdoc-main] [pasdoc:patches] #4 Inherited comments, @implements tag

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[patches:#4] Inherited comments, @implements tag**

**Status:** closed
**Group:** 
**Created:** Thu Jul 10, 2008 10:08 PM UTC by Michalis Kamburelis
**Last Updated:** Mon Mar 30, 2026 01:59 AM UTC
**Owner:** Michalis Kamburelis


This is a patch from Ilya Illarionov, that (for various reasons...) was lying unapplied on Michalis disk. I'm submitting it here, so it will get applied (or at least decided about) eventually --- probably after merging some DoDi work, to stabilize a little.

Below I'm pasting the relevant comments about the patch from Ilya Illarionov.

----

4. FEATURE: INHERITED COMMENTS (Common core. Output implemented in HtmlDoc
only.) Some Pascal items (classes, virtual overridden class methods, class
properties, overloaded routines and class methods) can inherit absent
comment parts (parameters, abstracts, descriptions etc.) from their
ancestors automatically. Using inherited comments author doesn't have to
specify comments for each inherited item in class, just declarations. Such
approach facilitates a writing of inherited elements, at the same time
provides full documentation generated by PasDoc for inherited items.

For example:
{ @abstract Basic class
  Basic description }
TBasic = class
 { @abstract Method to perform something
    Method description
   @param Param Some param }
 procedure BasicMethod(Param : Type); virtual; end;

{ @abstract Inherited class }
TInherited = class(TBasic)
 procedure BasicMethod(Param : Type); override; end;

In spite of absent comments for TInherited class, PasDoc will fully document
TInherited.BasicMethod, using comments from ancestor. For TInherited class
itself PasDoc will use abstract "Inherited class" but description (since its
own description is empty) "Basic Description".

5. FEATURE: @IMPLEMENTS keyword. Comments inheritance mechanism for
INHERITED COMMENTS. Using specified ancestor instead of automatic ancestor
search. Very useful for documenting class member that implements behaviours
for interfaces (eventually implemented by class) or other objects that are
related to such a member.

For example:
MyInterface = interface(IInterface)
 { @abstract Does something
      Some description
   @param Param Necessary parameter }
 procedure InterfaceMethod(Param : OleVariant); end;

{ @abstract MyInterface implementation } MyClass = class(TInterfacedObject,
IInterface)
 { @implements MyInterface.InterfaceMethod }
 procedure InterfaceMethod(Param : OleVariant); end;

Author does not need to copy comments from interface method to its
implementation, he just have to mark class method as an implementation of
interface method.

Next example:

TNestedClass = class;

TBoundaryClass = class
private
 FNested : TNestedClass;
public
 { @abstract Some Action
   @param Param Some param }
 procedure PerformBoundaryAction (Param : Variant); end; .....
procedure TBoundaryClass.PerformBoundaryAction (Param : Variant); begin
 if Assigned(FNested) then FNested.PerformMyAction(Param); end;

TNestedClass=class
public
 { @implements TBoundaryClass.PerformBoundaryAction }
 procedure PerformMyAction(Param : Variant); virtual; abstract; end;

Author does not need to copy comments from owning class method to nested
class method (and vice versa), but he points the fact that nested class
method have to be called from boundary class as dynamic behaviour
implementation.

6. Some win-1251, KOI8-R, cp866 translation was done.

7. FEATURE: "All members", "All fields", "All methods", "All properties"
(including inherited) links added to CIO documentation page (for HTML output
only).

8. ADDON: DPRUNITLIST unitily is implemented (source code available with
free third party regexp library). This console utility outputs to STDOUT
(using absolute or relative path) units being directly included into Delphi
Project.

9. FEATURE: @param, @returns, @raises keywords are added to class
properties. Reading property via PropGet method can raises an exception,
doesn't it? And array properties can have one or more parameters.

----

Please, remove any ILLARIONOV signatures from source files before you will
publish them. You may refer to me (if you want) in some unit headers. My
name is Ilya Illarionov, and actual e-mail is <billythekidd AT mail DOT ru>.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:patches] #4 Inherited comments, @implements tag

[Michalis K. <ka...@us...>]

Comments from inherited things are now used for classes and class members. Realistically, this is an old patch which will not apply anymore. If anything is missing from latest PasDoc, please submit PR to the latest code on GitHub: https://github.com/pasdoc/pasdoc/pulls


---

**[patches:#4] Inherited comments, @implements tag**

**Status:** open
**Group:** 
**Created:** Thu Jul 10, 2008 10:08 PM UTC by Michalis Kamburelis
**Last Updated:** Mon Jun 30, 2014 10:39 PM UTC
**Owner:** nobody


This is a patch from Ilya Illarionov, that (for various reasons...) was lying unapplied on Michalis disk. I'm submitting it here, so it will get applied (or at least decided about) eventually --- probably after merging some DoDi work, to stabilize a little.

Below I'm pasting the relevant comments about the patch from Ilya Illarionov.

----

4. FEATURE: INHERITED COMMENTS (Common core. Output implemented in HtmlDoc
only.) Some Pascal items (classes, virtual overridden class methods, class
properties, overloaded routines and class methods) can inherit absent
comment parts (parameters, abstracts, descriptions etc.) from their
ancestors automatically. Using inherited comments author doesn't have to
specify comments for each inherited item in class, just declarations. Such
approach facilitates a writing of inherited elements, at the same time
provides full documentation generated by PasDoc for inherited items.

For example:
{ @abstract Basic class
  Basic description }
TBasic = class
 { @abstract Method to perform something
    Method description
   @param Param Some param }
 procedure BasicMethod(Param : Type); virtual; end;

{ @abstract Inherited class }
TInherited = class(TBasic)
 procedure BasicMethod(Param : Type); override; end;

In spite of absent comments for TInherited class, PasDoc will fully document
TInherited.BasicMethod, using comments from ancestor. For TInherited class
itself PasDoc will use abstract "Inherited class" but description (since its
own description is empty) "Basic Description".

5. FEATURE: @IMPLEMENTS keyword. Comments inheritance mechanism for
INHERITED COMMENTS. Using specified ancestor instead of automatic ancestor
search. Very useful for documenting class member that implements behaviours
for interfaces (eventually implemented by class) or other objects that are
related to such a member.

For example:
MyInterface = interface(IInterface)
 { @abstract Does something
      Some description
   @param Param Necessary parameter }
 procedure InterfaceMethod(Param : OleVariant); end;

{ @abstract MyInterface implementation } MyClass = class(TInterfacedObject,
IInterface)
 { @implements MyInterface.InterfaceMethod }
 procedure InterfaceMethod(Param : OleVariant); end;

Author does not need to copy comments from interface method to its
implementation, he just have to mark class method as an implementation of
interface method.

Next example:

TNestedClass = class;

TBoundaryClass = class
private
 FNested : TNestedClass;
public
 { @abstract Some Action
   @param Param Some param }
 procedure PerformBoundaryAction (Param : Variant); end; .....
procedure TBoundaryClass.PerformBoundaryAction (Param : Variant); begin
 if Assigned(FNested) then FNested.PerformMyAction(Param); end;

TNestedClass=class
public
 { @implements TBoundaryClass.PerformBoundaryAction }
 procedure PerformMyAction(Param : Variant); virtual; abstract; end;

Author does not need to copy comments from owning class method to nested
class method (and vice versa), but he points the fact that nested class
method have to be called from boundary class as dynamic behaviour
implementation.

6. Some win-1251, KOI8-R, cp866 translation was done.

7. FEATURE: "All members", "All fields", "All methods", "All properties"
(including inherited) links added to CIO documentation page (for HTML output
only).

8. ADDON: DPRUNITLIST unitily is implemented (source code available with
free third party regexp library). This console utility outputs to STDOUT
(using absolute or relative path) units being directly included into Delphi
Project.

9. FEATURE: @param, @returns, @raises keywords are added to class
properties. Reading property via PropGet method can raises an exception,
doesn't it? And array properties can have one or more parameters.

----

Please, remove any ILLARIONOV signatures from source files before you will
publish them. You may refer to me (if you want) in some unit headers. My
name is Ilya Illarionov, and actual e-mail is <billythekidd AT mail DOT ru>.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #2 add a wiki &quot; markup&quot; parser

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **Group**:  --> 



---

**[feature-requests:#2] add a wiki "markup" parser**

**Status:** closed
**Group:** 
**Created:** Thu May 01, 2003 06:28 PM UTC by Johannes Berg
**Last Updated:** Mon Mar 30, 2026 01:56 AM UTC
**Owner:** Johannes Berg


When writing documentation, it can sometimes be very convenient to be able to write things in "<b>bold</b>" or "<i>italic</i>", make lists with "<ul><li>" etc.

This is just being discussed on the mailing list, and Thomas says that the output should change all characters into their respective HTML entities. This would mean that such code as I wrote above is written as-is, and displayed, instead of being printed. I think that is the correct way to handle it, getting rid of those strange "@<" and "@>" constructs.

But on the other hand, I do think that some documentation formatting is needed. But this again is impossible to produce in - for example - latex output, because there this is completely different. So the real solution to this is to add a (very) limited HTML parser, that can recognise only the basic tags:
 <b>, <i>, <ul>, <li>
and maybe something along the lines of pseudo-html:
 <red>, <green>, <blue>, <#1278EF> for colours
all along their respective closing tags (closing tag for colour would be </#> then).
This parser would have to have a generic interface so that each output generator would be able to provide the correct translation. I think error checking should be kept rather low, it is the developer's responsibility to feed this something sane (ie, if the output breaks, don't bother in the program).



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #2 add a wiki &quot; markup&quot; parser

[Michalis K. <ka...@us...>]

We have Markdown syntax now, which addresses this issue I believe: https://pasdoc.github.io/MarkdownOption


---

**[feature-requests:#2] add a wiki "markup" parser**

**Status:** open
**Group:** 
**Created:** Thu May 01, 2003 06:28 PM UTC by Johannes Berg
**Last Updated:** Mon Nov 05, 2012 10:16 AM UTC
**Owner:** Johannes Berg


When writing documentation, it can sometimes be very convenient to be able to write things in "<b>bold</b>" or "<i>italic</i>", make lists with "<ul><li>" etc.

This is just being discussed on the mailing list, and Thomas says that the output should change all characters into their respective HTML entities. This would mean that such code as I wrote above is written as-is, and displayed, instead of being printed. I think that is the correct way to handle it, getting rid of those strange "@<" and "@>" constructs.

But on the other hand, I do think that some documentation formatting is needed. But this again is impossible to produce in - for example - latex output, because there this is completely different. So the real solution to this is to add a (very) limited HTML parser, that can recognise only the basic tags:
 <b>, <i>, <ul>, <li>
and maybe something along the lines of pseudo-html:
 <red>, <green>, <blue>, <#1278EF> for colours
all along their respective closing tags (closing tag for colour would be </#> then).
This parser would have to have a generic interface so that each output generator would be able to provide the correct translation. I think error checking should be kept rather low, it is the developer's responsibility to feed this something sane (ie, if the output breaks, don't bother in the program).



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #3 Parsed store persistence

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **Group**:  --> 



---

**[feature-requests:#3] Parsed store persistence**

**Status:** closed
**Group:** 
**Created:** Fri May 09, 2003 04:52 PM UTC by Johannes Berg
**Last Updated:** Mon Mar 30, 2026 01:55 AM UTC
**Owner:** Johannes Berg


http://sourceforge.net/mailarchive/forum.php?thread_id=2058513&forum_id=4647

requested there, will try implementing soon. Read my follow-up once it shows up on the archive.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #3 Parsed store persistence

[Michalis K. <ka...@us...>]

Closing -- the original thread (linked from description of this issue) is not available anymore, and I think we have addressed everything we practically want from this :) In particular, format-independent cache in PasDoc rocks.


---

**[feature-requests:#3] Parsed store persistence**

**Status:** open
**Group:** 
**Created:** Fri May 09, 2003 04:52 PM UTC by Johannes Berg
**Last Updated:** Mon Nov 05, 2012 10:16 AM UTC
**Owner:** Johannes Berg


http://sourceforge.net/mailarchive/forum.php?thread_id=2058513&forum_id=4647

requested there, will try implementing soon. Read my follow-up once it shows up on the archive.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #20 4 question....

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#20] 4 question....**

**Status:** closed
**Group:** 
**Created:** Mon Jun 21, 2004 05:17 AM UTC by CETT
**Last Updated:** Mon Mar 30, 2026 01:53 AM UTC
**Owner:** Michalis Kamburelis


Hi everyone!

So, I have 4 question:
------------------------------------------------------
------------------
1: How to create multiline description? If I use this:
{ @author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)
@abstract(temp)
line1
line2
line3}

or this:

{ @author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)
@abstract(temp)}
{line1}
{line2}
{line3}

description, then a pasdoc generate this HTML text: 
</h2>temp<p>line1 line2
line3</p> WHY??? I think, the god HTML text is:
</h2>temp<p>line1<BR>line2<BR>line3</p>
------------------------------------------------------
------------------
2: How to use the @created, @author and @lastmod 
tags in the procedures and
functions description?
If I use this:
{ Description 
@param(param: input parameter)
@returns(output)
@author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)}
function func(param:string):String;

description, then a pasdoc add the HTML file is only 
@param and @returns
tag... WHY??? And the more tags?
------------------------------------------------------
------------------
3: How to add the html output a local variables, and the 
local variables
descriptions?
If I use this description to the main.pas:

function Tmainform.Encrypt(s: string): string; var
{ i temporary variables...}
i: integer;

then the pasdoc not added the local variables and local 
variables
descriptions to the main.tmainform.html file in the 
encrypt function
subsection...
------------------------------------------------------
------------------
4: If I use this unit:

unit Main;
interface
uses
Windows, Form, SysUtils, Variants, Classes, Controls, 
Graphics;
type
TMainForm = class(TForm)
MainMenu1: TMainMenu;
Menu_Exit: TMenuItem;
private
public
end;

Var MainForm: TMainForm;
implementation

uses my_unit1, my_unit2;
{$R *.dfm}
..............

then the generated html file is:
uses
-Windows
-Messages
-SysUtils
-Variants
-Classes
-Controls
-Graphics

OK. But where is my units? (my_unit1, my_unit2)
------------------------------------------------------
------------------
Thx for answers, bye:

Jónás Gergő



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #20 4 question....

[Michalis K. <ka...@us...>]

> Summary: I treat this request as partially fixed. The only
remaining issue here is number 2: using @created, @author
and @lastmod for all items. 

This has been done long time ago :) `@created`, `@author`, `@lastmod` work for all items. 

Other points from this were addressed already, from what I can see. Closing:)


---

**[feature-requests:#20] 4 question....**

**Status:** open
**Group:** 
**Created:** Mon Jun 21, 2004 05:17 AM UTC by CETT
**Last Updated:** Thu Jan 01, 2015 08:34 PM UTC
**Owner:** nobody


Hi everyone!

So, I have 4 question:
------------------------------------------------------
------------------
1: How to create multiline description? If I use this:
{ @author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)
@abstract(temp)
line1
line2
line3}

or this:

{ @author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)
@abstract(temp)}
{line1}
{line2}
{line3}

description, then a pasdoc generate this HTML text: 
</h2>temp<p>line1 line2
line3</p> WHY??? I think, the god HTML text is:
</h2>temp<p>line1<BR>line2<BR>line3</p>
------------------------------------------------------
------------------
2: How to use the @created, @author and @lastmod 
tags in the procedures and
functions description?
If I use this:
{ Description 
@param(param: input parameter)
@returns(output)
@author(Jónás Gergő <jon...@ch...>)
@created(2004.06.01.)
@lastmod(2004.06.01.)}
function func(param:string):String;

description, then a pasdoc add the HTML file is only 
@param and @returns
tag... WHY??? And the more tags?
------------------------------------------------------
------------------
3: How to add the html output a local variables, and the 
local variables
descriptions?
If I use this description to the main.pas:

function Tmainform.Encrypt(s: string): string; var
{ i temporary variables...}
i: integer;

then the pasdoc not added the local variables and local 
variables
descriptions to the main.tmainform.html file in the 
encrypt function
subsection...
------------------------------------------------------
------------------
4: If I use this unit:

unit Main;
interface
uses
Windows, Form, SysUtils, Variants, Classes, Controls, 
Graphics;
type
TMainForm = class(TForm)
MainMenu1: TMainMenu;
Menu_Exit: TMenuItem;
private
public
end;

Var MainForm: TMainForm;
implementation

uses my_unit1, my_unit2;
{$R *.dfm}
..............

then the generated html file is:
uses
-Windows
-Messages
-SysUtils
-Variants
-Classes
-Controls
-Graphics

OK. But where is my units? (my_unit1, my_unit2)
------------------------------------------------------
------------------
Thx for answers, bye:

Jónás Gergő



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #22 JavaDoc-like Tag handling

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#22] JavaDoc-like Tag handling**

**Status:** closed
**Group:** 
**Created:** Sun Apr 24, 2005 09:17 PM UTC by Damien Honeyford
**Last Updated:** Mon Mar 30, 2026 01:49 AM UTC
**Owner:** Michalis Kamburelis


A couple of things that I think would absolutely love to 
see PasDoc do -- firstly, be able to use un-
parenthesised tags, i.e.

@author    Damien
@abstract A little bit about this
@created  2005-04-24

I try to write all my doc comments in a way that they're 
just as easy to read, and hence just as useful, whilst 
developing as when they're compiled, and being able to 
do the above would improve the readablility 100% IMO.

Another thing I'd find immensely useful is being able to 
put my doc comments in the implementation section 
instead of the interface.  Personally, I like a clean and 
uncluttered interface so that I can easily see an overview 
of each class without having to worry about the details, 
no matter what editor I have to hand.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #22 JavaDoc-like Tag handling

[Michalis K. <ka...@us...>]

Parsing implementation comments is done: https://pasdoc.github.io/ImplementationCommentsOption


---

**[feature-requests:#22] JavaDoc-like Tag handling**

**Status:** open
**Group:** 
**Created:** Sun Apr 24, 2005 09:17 PM UTC by Damien Honeyford
**Last Updated:** Mon Nov 05, 2012 10:16 AM UTC
**Owner:** nobody


A couple of things that I think would absolutely love to 
see PasDoc do -- firstly, be able to use un-
parenthesised tags, i.e.

@author    Damien
@abstract A little bit about this
@created  2005-04-24

I try to write all my doc comments in a way that they're 
just as easy to read, and hence just as useful, whilst 
developing as when they're compiled, and being able to 
do the above would improve the readablility 100% IMO.

Another thing I'd find immensely useful is being able to 
put my doc comments in the implementation section 
instead of the interface.  Personally, I like a clean and 
uncluttered interface so that I can easily see an overview 
of each class without having to worry about the details, 
no matter what editor I have to hand.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #37 Including inherited class methods in documentation

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#37] Including inherited class methods in documentation**

**Status:** closed
**Group:** 
**Created:** Tue Mar 20, 2007 10:51 AM UTC by Anonymous
**Last Updated:** Mon Mar 30, 2026 01:46 AM UTC
**Owner:** Michalis Kamburelis


PasDoc is extremely good, but one thing which would add a lot of value to PasDoc would be to include a means of documenting the functions/procedures that can be called on a particular class.

atm, PasDoc will list all functions/procedures that a particular class *introduces* - but there's no way of finding out what it's really capable of


e.g. If you have:

type
  TClassOne = class(TComponent)
  public
    function MethodBase(): integer;
  end;

  TClassTwo = class(TClassOne)
  public
    function MethodSubclass(): integer;
  end;


The page for TClassTwo will list "MethodSubclass", but give no indication that "MethodBase" can also be called on this subclass.

This makes working with PasDoc's output a lot more difficult than it needs to be; in order to find out what methods you can call on a particular class involves looking at the documentation for that class, then the parent class, then that parent's class...

It would be *extremely* useful if a layout similar to that which Delphi's help file offers would be implemented as an option, which would give an at-a-glace view of what any given class offers.





---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #37 Including inherited class methods in documentation

[Michalis K. <ka...@us...>]

This was implemented recently:) See https://github.com/pasdoc/pasdoc/discussions/240


---

**[feature-requests:#37] Including inherited class methods in documentation**

**Status:** open
**Group:** 
**Created:** Tue Mar 20, 2007 10:51 AM UTC by Anonymous
**Last Updated:** Wed Oct 16, 2013 01:30 AM UTC
**Owner:** nobody


PasDoc is extremely good, but one thing which would add a lot of value to PasDoc would be to include a means of documenting the functions/procedures that can be called on a particular class.

atm, PasDoc will list all functions/procedures that a particular class *introduces* - but there's no way of finding out what it's really capable of


e.g. If you have:

type
  TClassOne = class(TComponent)
  public
    function MethodBase(): integer;
  end;

  TClassTwo = class(TClassOne)
  public
    function MethodSubclass(): integer;
  end;


The page for TClassTwo will list "MethodSubclass", but give no indication that "MethodBase" can also be called on this subclass.

This makes working with PasDoc's output a lot more difficult than it needs to be; in order to find out what methods you can call on a particular class involves looking at the documentation for that class, then the parent class, then that parent's class...

It would be *extremely* useful if a layout similar to that which Delphi's help file offers would be implemented as an option, which would give an at-a-glace view of what any given class offers.





---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #38 Support of @member in constante comment

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#38] Support of @member in constante comment**

**Status:** closed
**Group:** 
**Created:** Fri Apr 13, 2007 10:31 AM UTC by portail
**Last Updated:** Mon Mar 30, 2026 01:45 AM UTC
**Owner:** Michalis Kamburelis


If you want to comment a Windows Message you can't write the meaning of WParam, LParam ...etc

you can do this:

const
  {** Message send to .....
  @member WPARAM Handle of windows.
  @member LPARAM pointer of an object .}
  WMFW_NOTIFYFORMCLOSE = WM_APP + 1000;


Maybe it is not the good way to do this. Maybe sommething like:

const
  {** @message(Message send to ..... )
  @member WPARAM Handle of windows.
  @member LPARAM pointer of an object .}
  WMFW_NOTIFYFORMCLOSE = WM_APP + 1000;

The @message say it's a description of a message and @member is valid in this case. For a standard constant, you don't use @message and @member is not valid.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #38 Support of @member in constante comment

[Michalis K. <ka...@us...>]

I don't think we want to allow `@member` for this -- the idea of`@member` is to refer to existing member of given structure, https://pasdoc.github.io/MemberValueTag . The way to express what you need is indeed to use general formatting, like `@unorderedList`.


---

**[feature-requests:#38] Support of @member in constante comment**

**Status:** open
**Group:** 
**Created:** Fri Apr 13, 2007 10:31 AM UTC by portail
**Last Updated:** Wed Oct 16, 2013 02:02 AM UTC
**Owner:** nobody


If you want to comment a Windows Message you can't write the meaning of WParam, LParam ...etc

you can do this:

const
  {** Message send to .....
  @member WPARAM Handle of windows.
  @member LPARAM pointer of an object .}
  WMFW_NOTIFYFORMCLOSE = WM_APP + 1000;


Maybe it is not the good way to do this. Maybe sommething like:

const
  {** @message(Message send to ..... )
  @member WPARAM Handle of windows.
  @member LPARAM pointer of an object .}
  WMFW_NOTIFYFORMCLOSE = WM_APP + 1000;

The @message say it's a description of a message and @member is valid in this case. For a standard constant, you don't use @message and @member is not valid.



---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #46 Parse Comments in Implementation Section

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#46] Parse Comments in Implementation Section**

**Status:** closed
**Group:** 
**Created:** Tue Sep 15, 2009 05:17 PM UTC by Larry Hengen
**Last Updated:** Mon Mar 30, 2026 01:38 AM UTC
**Owner:** Michalis Kamburelis


PasDoc seems to work well, and I have adjusted my JavaDoc comments in hcOPF in order to use it, until I discovered that it does not extract comments from the implementation section.   This makes it unusable as far as I am concerned.  I have rather large comment blocks at the start of each method, and I want them to stay within the method commented so I can move the code without losing the comment attached to it.  It also makes more sense to have the comments as close to the actual code as possible so developers can understand the code easier by reading the comments that appear on the screen at the same time, and more importantly update the comments to ensure they are kept current.

Is this feature likely to be released any time soon, or should I search for  an alternative?


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #46 Parse Comments in Implementation Section

[Michalis K. <ka...@us...>]

Parsing implementations is available in PasDoc for some time now: https://pasdoc.github.io/ImplementationCommentsOption . Closing.


---

**[feature-requests:#46] Parse Comments in Implementation Section**

**Status:** open
**Group:** 
**Created:** Tue Sep 15, 2009 05:17 PM UTC by Larry Hengen
**Last Updated:** Fri Aug 08, 2014 09:09 PM UTC
**Owner:** nobody


PasDoc seems to work well, and I have adjusted my JavaDoc comments in hcOPF in order to use it, until I discovered that it does not extract comments from the implementation section.   This makes it unusable as far as I am concerned.  I have rather large comment blocks at the start of each method, and I want them to stay within the method commented so I can move the code without losing the comment attached to it.  It also makes more sense to have the comments as close to the actual code as possible so developers can understand the code easier by reading the comments that appear on the screen at the same time, and more importantly update the comments to ensure they are kept current.

Is this feature likely to be released any time soon, or should I search for  an alternative?


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #47 Support for interface realization

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#47] Support for interface realization**

**Status:** closed
**Group:** 
**Created:** Thu Sep 30, 2010 01:18 PM UTC by Anonymous
**Last Updated:** Mon Mar 30, 2026 01:36 AM UTC
**Owner:** Michalis Kamburelis


There is no support for interface realization in such way as for inheritance.
I.e. There is inheritance hierachy but there is no interface realization one. There is @inherited tag for inherited members but there are no resembled things for interface members to realize


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #47 Support for interface realization

[Michalis K. <ka...@us...>]

Interfaces are part of "hierarchy".
What interfaces are implemented by a given class is visible in that class docs, and in GraphViz graph (we cannot really show this in "hierarchy" since a class may implement multiple interfaces).
Closing - I think realistically we have implemented what is necessary. If anything remains, please submit a GitHub issue: https://github.com/pasdoc/pasdoc/issues


---

**[feature-requests:#47] Support for interface realization**

**Status:** open
**Group:** 
**Created:** Thu Sep 30, 2010 01:18 PM UTC by Anonymous
**Last Updated:** Mon Nov 05, 2012 10:17 AM UTC
**Owner:** nobody


There is no support for interface realization in such way as for inheritance.
I.e. There is inheritance hierachy but there is no interface realization one. There is @inherited tag for inherited members but there are no resembled things for interface members to realize


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #50 HTML-5 support

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis



---

**[feature-requests:#50] HTML-5 support**

**Status:** closed
**Group:** 
**Created:** Mon Dec 10, 2012 12:48 AM UTC by silvioprog
**Last Updated:** Mon Mar 30, 2026 01:33 AM UTC
**Owner:** Michalis Kamburelis


It would be nice to be this option:

```
--format=html-5
```

And it generates all the doc in HTML-5 format.

thx.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #50 HTML-5 support

[Michalis K. <ka...@us...>]

Done now in PasDoc 1.0.0: https://github.com/pasdoc/pasdoc/discussions/230 


---

**[feature-requests:#50] HTML-5 support**

**Status:** open
**Group:** 
**Created:** Mon Dec 10, 2012 12:48 AM UTC by silvioprog
**Last Updated:** Wed Oct 16, 2013 03:08 AM UTC
**Owner:** nobody


It would be nice to be this option:

```
--format=html-5
```

And it generates all the doc in HTML-5 format.

thx.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #54 Explicit @link doesn't work with urls

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#54] Explicit @link doesn't work with urls**

**Status:** closed
**Group:** 
**Created:** Wed Oct 30, 2013 01:29 PM UTC by Marcos Rocha
**Last Updated:** Mon Mar 30, 2026 01:31 AM UTC
**Owner:** Michalis Kamburelis


While making a documentation, I wrote in comment _{ See @link(http://pasdoc.sipsolutions.net/LinkTag this link) for more details }_ and the result in HTML generated document was _"See UNKNOWN for more details"_.

I would like to suggest the possibility to make explicit links using @link. =)


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #54 Explicit @link doesn't work with urls

[Michalis K. <ka...@us...>]

We've made a separate @ tag for URL links: https://pasdoc.github.io/UrlTag . This practically addresses this issue. We didn't "overuse" @ link to handle URLs, to keep things easier: @link is for Pascal items, @url is for URLs.


---

**[feature-requests:#54] Explicit @link doesn't work with urls**

**Status:** open
**Group:** 
**Created:** Wed Oct 30, 2013 01:29 PM UTC by Marcos Rocha
**Last Updated:** Wed Oct 30, 2013 11:18 PM UTC
**Owner:** nobody


While making a documentation, I wrote in comment _{ See @link(http://pasdoc.sipsolutions.net/LinkTag this link) for more details }_ and the result in HTML generated document was _"See UNKNOWN for more details"_.

I would like to suggest the possibility to make explicit links using @link. =)


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #60 Follow nested record types

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis
- **Group**:  --> 



---

**[feature-requests:#60] Follow nested record types**

**Status:** closed
**Group:** 
**Created:** Mon Dec 31, 2018 07:01 AM UTC by Colin Haywood
**Last Updated:** Mon Mar 30, 2026 01:29 AM UTC
**Owner:** Michalis Kamburelis


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.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:feature-requests] #60 Follow nested record types

[Michalis K. <ka...@us...>]

We have improved parsing nesting structures and linking to them in PasDoc 1.0.0, see https://github.com/pasdoc/pasdoc/blob/master/ChangeLog.md . So this should be fixed, please retest. If anything remains missing, please report on GitHub issues, https://github.com/pasdoc/pasdoc/issues . Thank you!


---

**[feature-requests:#60] Follow nested record types**

**Status:** open
**Group:** 
**Created:** Mon Dec 31, 2018 07:01 AM UTC by Colin Haywood
**Last Updated:** Tue Jan 01, 2019 12:08 AM UTC
**Owner:** nobody


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.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Pasdoc-main] [pasdoc:bugs] #87 auto link and duplicated names

[Michalis K. <ka...@us...>]

- **status**: open --> closed
- **assigned_to**: Michalis Kamburelis



---

**[bugs:#87] auto link and duplicated names**

**Status:** closed
**Version:** 0.14.0
**Created:** Sun Nov 08, 2015 09:21 PM UTC by Benito van der Zander
**Last Updated:** Mon Mar 30, 2026 01:26 AM UTC
**Owner:** Michalis Kamburelis


I have a type TX in unit A that is referenced in unit B as

    //* Just a wrapper to unit A. 
    type TX = unitA.TX;

If I write TX in the index document, it is auto linked to unitB.TX, when it should be autolinked to unit A.

If I write @noAutoLinkHere in unitB, TX in the index document is not autolinked anywhere, despite there still being the target in unitA.


---

Sent from sourceforge.net because pas...@li... is subscribed to https://sourceforge.net/p/pasdoc/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pasdoc/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.