doxygen-users — List for users of doxygen

[Doxygen-users] Virus rejected

[<pos...@vo...>]

Received: from [198.76.25.3] (HELO nns.voyanttech.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with SMTP id 1668047 for gle...@vo...; Thu, 13 Dec 2001 11:52:38 -0700
Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252])
	by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id MAA20822
	for <gle...@vo...>; Thu, 13 Dec 2001 12:54:13 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net)
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16Eavn-0002mk-00; Thu, 13 Dec 2001 10:50:07 -0800
Received: from gull.mail.pas.earthlink.net ([207.217.120.84] helo=gull.prod.itd.earthlink.net)
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16Eavd-0002ld-00
	for <dox...@li...>; Thu, 13 Dec 2001 10:49:57 -0800
Received: from lsanca1-ar4-225-073.elnk.dsl.gtei.net ([4.33.225.73] helo=dhcppc1)
	by gull.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 16Eavc-0002qD-00
	for dox...@li...; Thu, 13 Dec 2001 10:49:56 -0800
From: Ted Drain <ted...@ea...>
To: dox...@li...
Message-Id: <200...@ea...>
X-Mailer: Sylpheed version 0.6.5claws8 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Thu__13_Dec_2001_10:51:28_-0800_0821bfe8"
Subject: [Doxygen-users] Patch for showing inherited members in a derived class
Sender: dox...@li...
Errors-To: dox...@li...
X-BeenThere: dox...@li...
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:dox...@li...?subject=help>
List-Post: <mailto:dox...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=subscribe>
List-Id: <doxygen-users.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=doxygen-users>
X-Original-Date: Thu, 13 Dec 2001 10:51:28 -0800
Date: Thu, 13 Dec 2001 10:51:28 -0800

This is a multi-part message in MIME format.

--Multipart_Thu__13_Dec_2001_10:51:28_-0800_0821bfe8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Attached is a patch (for two files) that does the following:

1) Added a new configuration boolean value SHOW_INHERITED_MEMBERS 
2) If this value is set to YES, the main documentation page for a derived class will show all it's members - those defined in the class plus those inherited from any base classes.  In affect, this adds the items listed in the 'List of all members' link into the main docs for a class.  

To use the patch:
1) get the latest doxygen source from CVS
2) cd doxygen/src
3) patch < config.l-patch
4) patch < classdef.cpp-patch
5) rebuild

The patches were generated from the version of doxygen in the CVS repository as of 13-dec-2001 09:00 PST.

I've tested the patch for quite a few cases and it seems to work fine.  If you find any problems please let me know.  

Dimitri: Is there any chance this capability could be incorporated in the main doxgen code?  

Ted
--Multipart_Thu__13_Dec_2001_10:51:28_-0800_0821bfe8
Content-Type: application/octet-stream;
 name="config.l-patch"
Content-Disposition: attachment;

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THE ATTACHMENT CONTAINED AN INVALID EXTENSION OF '.l-patch'

[Doxygen-users] Patch for showing inherited members in a derived class

[Ted D. <ted...@ea...>]

Attached is a patch (for two files) that does the following:

1) Added a new configuration boolean value SHOW_INHERITED_MEMBERS 
2) If this value is set to YES, the main documentation page for a derived class will show all it's members - those defined in the class plus those inherited from any base classes.  In affect, this adds the items listed in the 'List of all members' link into the main docs for a class.  

To use the patch:
1) get the latest doxygen source from CVS
2) cd doxygen/src
3) patch < config.l-patch
4) patch < classdef.cpp-patch
5) rebuild

The patches were generated from the version of doxygen in the CVS repository as of 13-dec-2001 09:00 PST.

I've tested the patch for quite a few cases and it seems to work fine.  If you find any problems please let me know.  

Dimitri: Is there any chance this capability could be incorporated in the main doxgen code?  

Ted

RE: [Doxygen-users] Including other docs via TAGFILES does not work asexpected

[Morgenthaler, G. <g.m...@vi...>]

> How do I reference the \mainpage or other \sections of the=20
> client systems, e.g. boblib and flclib from the parent system
> flcman?

Now _that_ is a good question.

I think you can't (in a nice way)? Or should I say you wouldn't
want to? ;-)

My normal use is to wrap the different "documentation systems"
with a handmade HTML page, linking to the main pages with a
direct link to index.html. That should work quite nice as I think
the name of the index.html file should be pretty stable.

Linking to \sections is really a problem. Coding the created
doxygen file names into my code is NOT something that attracts
me. So I just don't do it.

Now for the "you wouldn't want to": normally you follow the
link from the program to the library (you wanted to look up
something, right?) and when you are there you have the page
menu at the top where you can select the \sections of the
library documentation. It's just a few click away...

Anyway, if anybody has a nice solution I would be interested
in an answer too.

Regards, Germar

Re: [Doxygen-users] Feature Req: show inherited members w/ class docs

[<cy...@so...>]

> I have a hacked together version of doxygen that merges base class members
> (functions, enums, etc) into the derived class if the derived class
doesn't
> have anything w/ that name already.  So far, it has worked w/ the test
> cases I've tried.  I'm going to try to clean up what I did and I'll send
> you a patch if you're interested.

Sounds very interesting; thanks a lot !

    -- Cyrille

[Doxygen-users] bug with INLINE_SOURCES producing duplicate inlinings

[<ric...@gr...>]

It seems like setting INLINE_SOURCES to "YES" results in duplicate
inlining of the source in documentation files using doxygen
1.2.12. Attached tar file has two small files a.c and b.c as shown
below.

    // File a.c:

    extern void b1();

    void a1()
    {
        b1();
    }

    void a2()
    {
    }

    // File b.c:

    /**
     * To be or not to be, ...
     */
    void b1()
    {
    }

The tar file also has Doxyfile which sets INLINE_SOURCES to "YES".

The fact that b_8c.html has the body of b1() inlined is not
surprising. The problem is that a_8c.html also has the body of b1()
inlined even though a1.c only has an "extern" declaration of b1().

Re: [Doxygen-users] Including other docs via TAGFILES does not work asexpected

[Dimitri v. H. <di...@st...>]

On Wed, Dec 12, 2001 at 04:45:36PM +0100, Morgenthaler, Germar wrote:
> 
> > Your statement is only partly true. Installdox isn't just for moving a
> > system or search.
> > If you are creating a system out of multiple Doxygen runs and one
> system
> > depends/inherits from another, you would:
> 1) Have the parent system generate a tag file.
> 2) Have the child system reference the tag file.
> 3) Later, after the system is built, use installdox to resolve inherited
> references.
> 
> And I thought I'm doing exactly this without needing step 3) ;-)
> 
[snip]
> 
> The links in flcman documentation are resolved to boblib and flclib.
> 
> Still no installdox involved.

Germar is right. One should not have to deal with installdox, unless there are
plans to move the docs without regeneration. If you have two projects 
referencing each other, more than one run of doxygen is needed to bootstrap
though.

Regards,
  Dimitri

Re: [Doxygen-users] Comment Folding Problem

[Dimitri v. H. <di...@st...>]

On Wed, Dec 12, 2001 at 12:00:57PM -0500, Christian Ratliff wrote:
> 
>   I am using doxygen-1.2.6 and I am having a small problem with how the
> brief and detailed comments in a method are folded together. In my header
> file I have something like:
> 
> /** Describes method briefly starting with a  verb. */
> void MyMethod(int myparameter);

I would have expected a @brief here (and JAVADOC_AUTOBRIEF to NO).
You cannot have two detailed or two brief descriptions (in any version of
doxygen so far).

> In my source file I then have:
> 
> /**
>  * More detailed information about the method. Possibly
>  * many sentences or paragraphs with embedded HTML. The
>  * brief comment is not restated.
>  *
>  * @param myparameter Information about the parameter.
>  */
> void MyClass::MyMethod(int myparameter)
> {
>   // ...
> }
> 
>   The trouble I am having is that doxygen-1.2.6 appears to assume the first
> sentence in the source file comment is a restatement of the brief comment
> from the header file. This isn't the case, and I want to tell it not to
> delete the first sentence.
>   I thought I saw this was fixed in a more recent version of doxygen, but I
> cannot update to the latest version. 

Why not? You wouldn't want to continue with that release forever, would you?

Regards, 
  Dimitri

Re: [Doxygen-users] Including other docs via TAGFILES does not work asexpected

[Thomas Z. <zi...@co...>]

A related question:

How do I reference the \mainpage or other \sections of the client systems,
e.g. boblib and flclib from the parent system flcman?

Thanks in advance,
Thomas

On Wed, Dec 12, 2001 at 04:45:36PM +0100, Morgenthaler, Germar wrote:
> 
> > Your statement is only partly true. Installdox isn't just for moving a
> > system or search.
> > If you are creating a system out of multiple Doxygen runs and one
> system
> > depends/inherits from another, you would:
> 1) Have the parent system generate a tag file.
> 2) Have the child system reference the tag file.
> 3) Later, after the system is built, use installdox to resolve inherited
> references.
> 
> And I thought I'm doing exactly this without needing step 3) ;-)
> 
> I have a library at:
> 
> ~/src/boblib/*.cpp *.hpp
> ~/src/boblib/doc/doxygen.cfg
> 
> I have a library at:
> 
> ~/src/flclib/*.cpp *.hpp
> ~/src/flclib/doc/doxygen.cfg
> 
> And a program that uses that libraries at:
> 
> ~/src/flcman/*.cpp *.hpp
> ~/src/flcman/doc/doxygen.cfg
> 
> What I do is:
> 
> 1) I create the documentation and tagfile for boblib in
> ~/src/boblib/doc/boblib.tag
> ~/src/boblib/doc/html/
> thru running doxygen doxygen.cfg in
> ~/src/boblib/doc
> 
> 2) I create the documentation and tagfile for flclib in
> ~/src/flclib/doc/boblib.tag
> ~/src/flclib/doc/html/
> thru running doxygen doxygen.cfg in
> ~/src/flclib/doc
> 
> 3) I create the documentation for flcman in
> ~src/flcman/doc/html/
> with:
> TAGFILES = ../../boblib/doc/boblib.tag=../../../boblib/doc/html \
>            ../../flclib/doc/flclib.tag=../../../flclib/doc/html
> thru running doxygen doxygen.cfg in
> ~/src/flcman/doc
> 
> The links in flcman documentation are resolved to boblib and flclib.
> 
> Still no installdox involved.
> 
> Regards, Germar
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

-- 
Dr.-Ing. Thomas Ziegler            |
Senior Research Engineer           | Coding Technologies
phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
fax:   +49 (0) 911 92891 -99       | D-90429 Nürnberg, Germany
mailto:zi...@Co...  | http://www.CodingTechnologies.com

[Doxygen-users] Comment Folding Problem

[Christian R. <cra...@de...>]

  I am using doxygen-1.2.6 and I am having a small problem with how the
brief and detailed comments in a method are folded together. In my header
file I have something like:

/** Describes method briefly starting with a  verb. */
void MyMethod(int myparameter);

In my source file I then have:

/**
 * More detailed information about the method. Possibly
 * many sentences or paragraphs with embedded HTML. The
 * brief comment is not restated.
 *
 * @param myparameter Information about the parameter.
 */
void MyClass::MyMethod(int myparameter)
{
  // ...
}

  The trouble I am having is that doxygen-1.2.6 appears to assume the first
sentence in the source file comment is a restatement of the brief comment
from the header file. This isn't the case, and I want to tell it not to
delete the first sentence.
  I thought I saw this was fixed in a more recent version of doxygen, but I
cannot update to the latest version. Can the person who provided that fix
let me know what the code change was so I can patch my 1.2.6 source and
rebuild? A patch file is not intrinsically necessary. I deeply appreciate
any efforts on this issue.

thank you very much,
christian

+-----+
Christian Ratliff <cra...@de...>
Sr. Technology Architect / Core Libraries Group
DeLorme Publishing Co.
"This is the very perfection of man, 
  to find out his own imperfections" -  St. Augustine

RE: [Doxygen-users] Including other docs via TAGFILES does not work asexpected

[Morgenthaler, G. <g.m...@vi...>]

> Your statement is only partly true. Installdox isn't just for moving a
> system or search.
> If you are creating a system out of multiple Doxygen runs and one
system
> depends/inherits from another, you would:
1) Have the parent system generate a tag file.
2) Have the child system reference the tag file.
3) Later, after the system is built, use installdox to resolve inherited
references.

And I thought I'm doing exactly this without needing step 3) ;-)

I have a library at:

~/src/boblib/*.cpp *.hpp
~/src/boblib/doc/doxygen.cfg

I have a library at:

~/src/flclib/*.cpp *.hpp
~/src/flclib/doc/doxygen.cfg

And a program that uses that libraries at:

~/src/flcman/*.cpp *.hpp
~/src/flcman/doc/doxygen.cfg

What I do is:

1) I create the documentation and tagfile for boblib in
~/src/boblib/doc/boblib.tag
~/src/boblib/doc/html/
thru running doxygen doxygen.cfg in
~/src/boblib/doc

2) I create the documentation and tagfile for flclib in
~/src/flclib/doc/boblib.tag
~/src/flclib/doc/html/
thru running doxygen doxygen.cfg in
~/src/flclib/doc

3) I create the documentation for flcman in
~src/flcman/doc/html/
with:
TAGFILES =3D ../../boblib/doc/boblib.tag=3D../../../boblib/doc/html \
           ../../flclib/doc/flclib.tag=3D../../../flclib/doc/html
thru running doxygen doxygen.cfg in
~/src/flcman/doc

The links in flcman documentation are resolved to boblib and flclib.

Still no installdox involved.

Regards, Germar

RE: [Doxygen-users] Including other docs via TAGFILES does not work asexpected

[Morgenthaler, G. <g.m...@vi...>]

> Anyhow, installdox will simply append what you submit after=20
> the @ sign to the links from the tag file before the @ sign.

Maybe I'm wrong but I think both of you don't need installdox as
installdox is only necessary if you want to change a path in an
already _created_ documentation after you moved it to another
location.

I "configure" my tagfile links at documentation creation time
with something like this:

TAGFILES =3D ../../boblib/doc/boblib.tag=3D../../../boblib/doc/html \
           ../../flclib/doc/flclib.tag=3D../../../flclib/doc/html

in my doxygen.cfg and don't use installdox at all.

Regards, Germar

Re: [Doxygen-users] Including other docs via TAGFILES does not work as expected

[<dr...@ca...>]

In the example, I wrongly assumed you were generating the tag file the
other way around.
Yet again I said it would look "something" like it. lol

Now, assuming that lib.tag is generated with ./lib/html/ documentation =
and
./html 's documentation references to it, then
the correct command should be :   installdox -l lib.tag@../lib/html  an=
d
runned from directory ./html/

Anyhow, installdox will simply append what you submit after the @ sign =
to
the links from the tag file before the @ sign.

html link Before:
     <a class=3D"codeRef" doxygen=3D"lib.tag:" href=3D"myReferencedFile=
.html">
MyReferencedFunction</a>
html link After:
     <a class=3D"codeRef" doxygen=3D"lib.tag:../lib/html" href=3D"../li=
b/html/
myReferencedFile.html"> MyReferencedFunction</a>




Thomas Ziegler <zi...@co...>@lists.sourceforge.net on
12/12/2001 07:47:12 AM

Sent by:  dox...@li...


To:   Denis Ricard/Toronto/IBM@IBMCA
cc:   dox...@li...
Subject:  Re: [Doxygen-users] Including other docs via TAGFILES does no=
t
      work as expected




On Tue, Dec 11, 2001 at 02:05:07PM -0500, dr...@ca... wrote:
>
> Did you try running installdox from the html directory? This will mod=
ify
> the links in the html to the other documentation's directory.
> Just type lib/html/installdox for command format.

I thought, that this message:

Now copy the file

     /home/zie/tmp/doxygent.tst/test/html/search.cgi

     to the directory where the CGI binaries are located and don't forg=
et
to
run

     /home/zie/tmp/doxygent.tst/test/html/installdox

to replace any dummy links.

was only meant for the search stuff (there is no search.cgi)

>
> For your program, it will be something like this : lib/html/installdo=
x -l
> lib.tag@../../html

It seems, that I do not understand clearly the syntax of installdox

 - ./html     contains the main module
              lib.tag is included here
                 html/installdox exists

 - ./lib/html contains the additional library
              lib.tag is generated here
                 no html/installdox exists

I tried from ./:

  html/installdox -l lib.tag@lib html/

which does not work.




>
> Installdox is very useful when your website has a different dir struc=
ture
> than your generated .html ...
>
>
>
> Thomas Ziegler <zi...@co...>@lists.sourceforge.net on
> 12/11/2001 01:20:55 PM
>
> Sent by:  dox...@li...
>
>
> To:   dox...@li...
> cc:
> Subject:  [Doxygen-users] Including other docs via TAGFILES does not =
work
>       as expected
>
>
> Hi all,
>
> I'm not able to include doxygen-docu of a library into another projec=
t if
> the source files reside in another (sub)-directory.
>
> I've attached a small example which looks like this:
>
> - ./test.dox
>   ./src/
>     - file1.c
>     - file1.h
>     - file2.c
>     - file2.h
>   ./lib/lib.dox
>   ./lib/src/
>         - file1.c
>         - file1.h
>            - file3.c
>            - file3.h
>
>
> File 'file1.c' contains a call to a library function 'lib2()' in
> 'lib/src/file3.c'
>
> The command
>
>   cd lib; doxygen lib.dox
>
> creates lib/html/... and the tagfile lib/lib.tag. lib/lib.tag is
referenced
> by test.dox. The command
>
>   doxygen test.dox
>
> creates ./html/...
>
> Browsing through the sources of ./html/file1_8c-source.html shows an
active
> link for lib2(). Unfortunately it points to an invalid location
> ./html/file3_8c.html#a0.
>
> I.e. the link points to the current html-subdir instead of the one in=

> lib/html.
>
> Any hints?
>
> Thanks in advance,
> Thomas
>
> PS: same behavior for 1.2.5 and 1.2.12
>
>
>
> --
> Dr.-Ing. Thomas Ziegler            |
> Senior Research Engineer           | Coding Technologies
> phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
> fax:   +49 (0) 911 92891 -99       | D-90429 N=FCrnberg, Germany
> mailto:zi...@Co...  | http://www.CodingTechnologies.co=
m
> (See attached file: test.zip)



--
Dr.-Ing. Thomas Ziegler            |
Senior Research Engineer           | Coding Technologies
phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
fax:   +49 (0) 911 92891 -99       | D-90429 N=FCrnberg, Germany
mailto:zi...@Co...  | http://www.CodingTechnologies.com

_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

=

Re: [Doxygen-users] Including other docs via TAGFILES does not work as expected

[Thomas Z. <zi...@co...>]

On Tue, Dec 11, 2001 at 02:05:07PM -0500, dr...@ca... wrote:
> 
> Did you try running installdox from the html directory? This will modify
> the links in the html to the other documentation's directory.
> Just type lib/html/installdox for command format.

I thought, that this message:

Now copy the file

     /home/zie/tmp/doxygent.tst/test/html/search.cgi
     
     to the directory where the CGI binaries are located and don't forget to
run

     /home/zie/tmp/doxygent.tst/test/html/installdox
     
to replace any dummy links.

was only meant for the search stuff (there is no search.cgi)

> 
> For your program, it will be something like this : lib/html/installdox -l
> lib.tag@../../html

It seems, that I do not understand clearly the syntax of installdox

 - ./html     contains the main module
              lib.tag is included here
	      html/installdox exists
 
 - ./lib/html contains the additional library
              lib.tag is generated here 
	      no html/installdox exists
	      
I tried from ./:

  html/installdox -l lib.tag@lib html/
  
which does not work.




> 
> Installdox is very useful when your website has a different dir structure
> than your generated .html ...
> 
> 
> 
> Thomas Ziegler <zi...@co...>@lists.sourceforge.net on
> 12/11/2001 01:20:55 PM
> 
> Sent by:  dox...@li...
> 
> 
> To:   dox...@li...
> cc:
> Subject:  [Doxygen-users] Including other docs via TAGFILES does not work
>       as expected
> 
> 
> Hi all,
> 
> I'm not able to include doxygen-docu of a library into another project if
> the source files reside in another (sub)-directory.
> 
> I've attached a small example which looks like this:
> 
> - ./test.dox
>   ./src/
>     - file1.c
>     - file1.h
>     - file2.c
>     - file2.h
>   ./lib/lib.dox
>   ./lib/src/
>         - file1.c
>         - file1.h
>            - file3.c
>            - file3.h
> 
> 
> File 'file1.c' contains a call to a library function 'lib2()' in
> 'lib/src/file3.c'
> 
> The command
> 
>   cd lib; doxygen lib.dox
> 
> creates lib/html/... and the tagfile lib/lib.tag. lib/lib.tag is referenced
> by test.dox. The command
> 
>   doxygen test.dox
> 
> creates ./html/...
> 
> Browsing through the sources of ./html/file1_8c-source.html shows an active
> link for lib2(). Unfortunately it points to an invalid location
> ./html/file3_8c.html#a0.
> 
> I.e. the link points to the current html-subdir instead of the one in
> lib/html.
> 
> Any hints?
> 
> Thanks in advance,
> Thomas
> 
> PS: same behavior for 1.2.5 and 1.2.12
> 
> 
> 
> --
> Dr.-Ing. Thomas Ziegler            |
> Senior Research Engineer           | Coding Technologies
> phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
> fax:   +49 (0) 911 92891 -99       | D-90429 Nürnberg, Germany
> mailto:zi...@Co...  | http://www.CodingTechnologies.com
> (See attached file: test.zip)



-- 
Dr.-Ing. Thomas Ziegler            |
Senior Research Engineer           | Coding Technologies
phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
fax:   +49 (0) 911 92891 -99       | D-90429 Nürnberg, Germany
mailto:zi...@Co...  | http://www.CodingTechnologies.com

[Doxygen-users] How can I ignore private nested classes?

[Simon P. <s.p...@la...>]

Hi,

I often use the C++ technique of a "private implementation pointer", i.e. the
header for a class contains a pointer to a private class that actually
implements the functionality of the class. This removes a lot of implementation
specific junk from the public header file and reduces unnecessary
re-compilation. 

Even though this implementation class is defined as a private nested class
within the main class, Doxygen generates documentation for it if EXTRACT_ALL is
set to YES and EXTRACT_PRIVATE is set to no. Is this a bug?

For example:

In MyObj.h:

-------------------------------------------

class MyObj {
 
private:

  struct Imp;
  Imp* imp;

public:

  MyObj();
  ~MyObj();

  void memberFunc();
};

-------------------------------------------



In MyObj.cc:

-------------------------------------------

#include "MyObj.h"

struct MyObj::Imp {

  // Implementation details
  // ...

  Imp() {  }

  void memberFunc() {   }

};

// Forwarding functions

MyObj::MyObj() {
  imp = new Imp();
}

MyObj::~MyObj() {
  delete imp;
}

void MyObj::memberFunc() {
  imp->memberFunc();
}

-------------------------------------------

Even though MyObj::Imp is a private nested class of MyObj, Doxygen generates
documentation for it if EXTRACT_ALL is set to YES, even though EXTRACT_PRIVATE
is set to NO. Is there any way of preventing documentation being generated for
these private implementation classes while still generating documentation for
all other undocumented things? 

Cheers,

Sy

Re: [Doxygen-users] Including other docs via TAGFILES does not work as expected

[<dr...@ca...>]

Did you try running installdox from the html directory? This will modif=
y
the links in the html to the other documentation's directory.
Just type lib/html/installdox for command format.

For your program, it will be something like this : lib/html/installdox =
-l
lib.tag@../../html

Installdox is very useful when your website has a different dir structu=
re
than your generated .html ...



Thomas Ziegler <zi...@co...>@lists.sourceforge.net on
12/11/2001 01:20:55 PM

Sent by:  dox...@li...


To:   dox...@li...
cc:
Subject:  [Doxygen-users] Including other docs via TAGFILES does not wo=
rk
      as expected


Hi all,

I'm not able to include doxygen-docu of a library into another project =
if
the source files reside in another (sub)-directory.

I've attached a small example which looks like this:

- ./test.dox
  ./src/
    - file1.c
    - file1.h
    - file2.c
    - file2.h
  ./lib/lib.dox
  ./lib/src/
        - file1.c
        - file1.h
           - file3.c
           - file3.h


File 'file1.c' contains a call to a library function 'lib2()' in
'lib/src/file3.c'

The command

  cd lib; doxygen lib.dox

creates lib/html/... and the tagfile lib/lib.tag. lib/lib.tag is refere=
nced
by test.dox. The command

  doxygen test.dox

creates ./html/...

Browsing through the sources of ./html/file1_8c-source.html shows an ac=
tive
link for lib2(). Unfortunately it points to an invalid location
./html/file3_8c.html#a0.

I.e. the link points to the current html-subdir instead of the one in
lib/html.

Any hints?

Thanks in advance,
Thomas

PS: same behavior for 1.2.5 and 1.2.12



--
Dr.-Ing. Thomas Ziegler            |
Senior Research Engineer           | Coding Technologies
phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
fax:   +49 (0) 911 92891 -99       | D-90429 N=FCrnberg, Germany
mailto:zi...@Co...  | http://www.CodingTechnologies.com
(See attached file: test.zip)
=

[Doxygen-users] Including other docs via TAGFILES does not work as expected

[Thomas Z. <zi...@co...>]

Hi all,

I'm not able to include doxygen-docu of a library into another project if
the source files reside in another (sub)-directory.

I've attached a small example which looks like this:

- ./test.dox
  ./src/
    - file1.c
    - file1.h
    - file2.c
    - file2.h
  ./lib/lib.dox
  ./lib/src/
        - file1.c
        - file1.h
	- file3.c
	- file3.h
	

File 'file1.c' contains a call to a library function 'lib2()' in
'lib/src/file3.c'

The command

  cd lib; doxygen lib.dox

creates lib/html/... and the tagfile lib/lib.tag. lib/lib.tag is referenced
by test.dox. The command

  doxygen test.dox
  
creates ./html/...

Browsing through the sources of ./html/file1_8c-source.html shows an active
link for lib2(). Unfortunately it points to an invalid location
./html/file3_8c.html#a0. 

I.e. the link points to the current html-subdir instead of the one in
lib/html.

Any hints?

Thanks in advance,
Thomas

PS: same behavior for 1.2.5 and 1.2.12



-- 
Dr.-Ing. Thomas Ziegler            |
Senior Research Engineer           | Coding Technologies
phone: +49 (0) 911 92891 -27       | Deutschherrnstr. 15-19
fax:   +49 (0) 911 92891 -99       | D-90429 Nürnberg, Germany
mailto:zi...@Co...  | http://www.CodingTechnologies.com

Re: [Doxygen-users] Feature Req: show inherited members w/ class docs

[<cy...@so...>]

> Would anyone else like this option?

I have asked a request in -devel a couple of weeks ago, which seems to have
been ignored. However, I wonder what this entry from the last CVS announce
means:

>>>>>>>>>>>>>>>>
+ ADD: Added some logic to deal with member specializations.
       They should now be added as additional members to a class instead of
       being ignored and producing a warning.
<<<<<<<<<<<<<<<<

Depending on the way to parse this, it could mean what we're both looking
for, or something different (I have to admit I just pipe the doxygen logs to
/dev/null for the time being)

    -- Cyrille

RE: [Doxygen-users] Feature Req: show inherited members w/ class docs

[Ted D. <The...@jp...>]

Here's the scenario:  We use an automated tool to generate a Python 
language binding for a subset of our c++ (subset of classes and subset of 
methods in classes).  We use a doxygen preprocessing script to identify 
these methods and filter so that the generated docs only contain the 
classes and functions available in the scripting language.  Our users (i.e. 
not "real" programmers ) use Python to script our applications.  If they're 
looking at the docs for class Derived, and it has methods available, they 
should be listed in the Derived docs, not in the docs on a separate page 
(show all members).  They really don't care whether a function is 
implemented in a base class or a derived class.

Ted

At 12/10/2001 09:12 AM, Morgenthaler, Germar wrote:
>Hi Ted,
>
> > I'd like to request an option in the config file to show all
> > inherited members with a derived class.
>
>What's wrong with the "List of all members" link in the
>class reference page?
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

RE: [Doxygen-users] Feature Req: show inherited members w/ class docs

[Morgenthaler, G. <g.m...@vi...>]

Hi Ted,

> I'd like to request an option in the config file to show all=20
> inherited members with a derived class.

What's wrong with the "List of all members" link in the
class reference page?

[Doxygen-users] Feature Req: show inherited members w/ class docs

[Ted D. <The...@jp...>]

I'd like to request an option in the config file to show all inherited 
members with a derived class.  So given the following:

class Base {
public:
         void f();
};

class Derived : public Base {
public:
         void g();
};

The docs for Derived would show both f and g.  The docs for f() might or 
might not appear on the same page as Derived.  The important part for me 
would by that the listing for Derived (at the top of the doc page) would 
include f().

I've spent a few hours trying to make this work by hacking classdef.cpp so 
that when the inherited elements are merged into the derived classes.  I 
couldn't get it to work, but I haven't spent that much time inside doxygen.

Would anyone else like this option?

Ted

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

RE: [Doxygen-users] Highlighted parameter names in function descr iptions

[<Car...@no...>]

Hi,

I understand it would not be most people's choice but I would hardly
describe it as a "show stopper" because:
- This behavior would be controlled by an option in the configuration file.
It would be off by default.
- Depending on your naming conventions you might not get these "false hits".

Now, if you want to point out that there's possibly too many options already
and that this would probably be handled better as a plugin or a post-process
(on the XML output perhaps), then I would have to agree with you.

Regards,
Carlos

-----Original Message-----
From: ext Victor A. Wagner, Jr. [mailto:va...@ru...]
Sent: 07. December 2001 14:53
To: Guerreiro Carlos (NRC/Helsinki)
Subject: RE: [Doxygen-users] Highlighted parameter names in function
descr iptions


the point that there would be "false hits" when arguments are normal (maybe 
even common) words in the describing language is a "show stopper", IMO.
no matter how "convenient' it might be for _your_ case, it would certainly 
adversely impact others.

At Friday 2001/12/07 05:43, you wrote:
>Thanks for the suggestion.
>I'm aware of this possibility but I would really prefer this to be done
>automatically be Doxygen, without any "markup".
>Has this feature been request by someone before? I couldn't find it in the
>wishlist in www.doxygen.org.
>
>Regards,
>Carlos
>
>
>-----Original Message-----
>From: ext Philippe Lhoste [mailto:Ph...@gm...]
>Sent: 07. December 2001 12:26
>To: dox...@li...
>Subject: Re:[Doxygen-users] Highlighted parameter names in function
>descriptions
>
>
> > We have started using Doxygen 1.2.12 (on a Linux box) for a small
project
> > here.
> > We are generally very pleased with Doxygen's output.
> > There's a small improvement I would like to propose though:
> >
> > - In the descriptions generated for functions and methods it would be
nice
> > to have the parameter names highlighted in some way (bold, colors, etc).
> >
> > It could be that there is some way of achieving this with some option in
>the
> > configuration file but after searching for this is the project manual I
> > found none. Any ideas?
>
>If, in the description of the function/method, you precede the parameter
>name by \a or @a (depending on the style you choose), its name will be
>italicized (with the <em> tag).
>You can change the stylesheet to modify the color or other apparence.
>Note: this is the way recommanded by the manual, but you can also use @b
>(bold), @c (typewritter), @e or @em (italics, same as @a, but the later
have
>a
>better structural meaning), @p (roughly same as @a, but use typewritter
font
>as @c).
>See the Commands reference for more informations.
>
>Regards.
>
>--
>--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
>Philippe Lhoste (Paris -- France)
>Professional programmer and amateur artist
>http://jove.prohosting.com/~philho/
>--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
>
>Sent through GMX FreeMail - http://www.gmx.net
>
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"

[Doxygen-users] Doxygen-1.2.12-20011209 in CVS

[Dimitri v. H. <di...@st...>]

Hi,

Here are the changes since the previous release:
-----------------------------------------------------------------------------
+ CHG: Changed the way @internal works. The "For internal use only" message,
       now appears (along with the internal documentation)
       if and only if INTERNAL_DOCS = YES.
+ CHG: Subgroups are no longer sorted but presented in declaration order.
+ CHG: Members inside todo/test/bug lists are now shown with qualified
       names again.
+ ADD: Added more info to the XML output: related pages, inner classes,
       inner namespaces.
+ ADD: Included language updates for German and Portuguese.
+ ADD: Added some logic to deal with member specializations.
       They should now be added as additional members to a class instead of
       being ignored and producing a warning.
+ ADD: Thanks to a patch by Bruce Korb, author of autogen, doxygen now
       has output support for producing autogen definition files. To do
       this set GENERATE_AUTOGEN_DEF to YES in the config file.
+ ADD: \relates can now be used for macros as well.
+ BUG: Documentation for nested classes inside other nested classes was
       not written to the output.
+ BUG: Fixed problem mixing paragraph commands (like \param) with
       hyphen-style lists.
+ BUG: Modules index in LaTeX was broken.
-----------------------------------------------------------------------------
Enjoy,
  Dimitri

Re: [Doxygen-users] Format glitch in 1.12

[Dimitri v. H. <di...@st...>]

On Thu, Dec 06, 2001 at 03:34:40PM -0800, Christopher Brewster wrote:
> An obscure change in the output format occurs in the
> upgrade from Dox 1.11 to 1.12. I am trying to show my
> co-workers how to create typical formatting, as shown
> in the file I posted recently (subject line, "Here are
> the graphic details"). Here is the source that creates
> varying outputs:
> ____________________________
> 
> \param param3   (12) This item has a blank line before
> it in the output
>       only because of the "br" tags before it in the
> source.  Here's a 
>       numbered list. To follow the list with a another
> "param" tag, use
>       no blank line. For blank lines in the output,
> "br" tags are needed.
> <br><br>
>  -#   First numbered item.
>  -#   Second numbered item.
>  -#   Third numbered item. <br><br>
> \param param4    This "param" tag needs to follow the
> list with no blank
>       line in the source, to prevent a repetition of
> the "Parameters" heading.
> ___________________________
> 
> I'm attaching .bmp files to show the difference.
> Before the paragraph for "param4", the "Parameters"
> heading is not repeated using Dox 1.11, but it is
> repeated with 1.12. So there was a change in what ends
> a \param block-- a numbered list or a blank line. 
> Under 1.12, there's no way to have a numbered list
> under a parameter description before the last one. Can
> the 1.11 behavior be put back in?

I'll fix this, and make it such that the <br>'s are not needed
and a blank is allowed after the above list.

Regards,
  Dimitri

[Doxygen-users] style question and grouping bug?

[Ted D. <ted...@ea...>]

The source code in my system is organized in two levels.  Packages are
collections of modules.  Modules are collections of classes and namespace
that perform a tightly coupled function.  I'm using doxygen grouping
commands to setup a page for each package that contains the modules and a
page for each module that contains the namespaces and classes in that
module.  The main doxygen module page then displays my packages (with
their modules indented).
 
In the package page, all of the modules in that package are listed in
reverse alphabetic order.  Is this a bug or am I not doing something
correctly?  

In the package pages, is there any way to get the brief description for
the module to be displayed next to the module name?

I really like the look of the namespace list and class list pages.  Is
there any way to apply this style to the group (package and module) pages
so that a module page would list it's namespaces and classes in the same
two column list that the main namespace/class list pages do?

Thanks,
Ted

[Doxygen-users] Hiding namespaces and merging namespace/class lists

[Ted D. <ted...@ea...>]

Two questions:

1) How hard would it be to add an option to merge the namespace and
compound lists?  Our developers don't really care if some piece of
functionality is implemented in a namespace or in a class so it would be
easier for them to find things if the lists were merged.  Any thoughts?

2) My project uses a single namespace for all the code written.  We want
to hide this namespace in the documentation.  I just upgraded to 1.2.12
from 1.2.6.  In 6, the HIDE_SCOPE_NAMES option did this.  In version 12,
the alphabetic list still shows the namespace name.  Is there any way to
get rid of this?

Thanks,
Ted