doxygen-users — List for users of doxygen

[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

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

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

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

Re:[Doxygen-users] Highlighted parameter names in function descriptions

[Philippe L. <Ph...@gm...>]

Additional note:

If you meant that Doxygen should automatically highlight parameters names in
the descriptions, I don't think this is a good idea..

What if we have parameters name that are simple English (or the language
used in the doc) words? There will be false hits if the description mixes these
words with the parameter names.
You can object that your project always use compound names, but I still
think it is better to explicitely mark these parameters. Plus it gives you
control, you can eg. use @a for 'in' parameters, and @p for 'out' ones.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

Sent through GMX FreeMail - http://www.gmx.net

Re:[Doxygen-users] Highlighted parameter names in function descriptions

[Philippe L. <Ph...@gm...>]

> 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] Highlighted parameter names in function descriptions

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

Hi,

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? 

Regards,
Carlos

[Doxygen-users] Format glitch in 1.12

[Christopher B. <bre...@ya...>]

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?

Christopher Brewster


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

[Doxygen-users] Doxygen and Java

[<Its...@t-...>]

Hi,

I used Doxygen in the past for documenting C++ code. Now I would like to
use it with Java.
But either I'm too dumb to configure Doxygen for Java, or it can't be
done, but here it is:

First problem:
Doxygen produces output like:

"void ActionPanel::ActionPanel()"

The problem is the "::". This is C++ style and I don't want that. I'd
rather have just a "." there. What can I do?

The second problem: I would like Doxygen to show what methods this
method references. 

And Doxygen produces:

"References bla,bla..". The problem: "References" is not a German word!
And I told Doxygen to create a German documentation. So how can I work
around this bug?

Thanx,

Sascha Herrmann

Re: [Doxygen-users] Documenting C code

[Bernd B. <bb...@fr...>]

Hi,

thanks to you and all others who replied!
Simply inserting a @file comment in my source files did the trick.

Regards,
Bernd

On Thursday 06 December 2001 07:18, Prikryl,Petr wrote:
> The simplified attachment is better than 1000 words.
> Please try to select some of the sources, including
> your Doxyfile, to reconstruct the problem.  As said
> in documentation, it is preferable when you do:
>
>     doxygen -s Doxyfile
>
> to strip the comments from your Doxyfile.
>
> Regards,
>   Petr

[Doxygen-users] Re: Possible bug with enums?

[Proskuriakov, I. <Igo...@gs...>]

The bug which I mentioned in my previous mail has gone in the latest doxygen
build from CVS sources.
 
Regards,
Igor Proskuriakov

RE: [Doxygen-users] Documenting C code

[Prikryl,Petr <PRI...@sk...>]

The simplified attachment is better than 1000 words.
Please try to select some of the sources, including
your Doxyfile, to reconstruct the problem.  As said 
in documentation, it is preferable when you do: 
   
    doxygen -s Doxyfile

to strip the comments from your Doxyfile.

Regards,
  Petr

> -----Original Message-----
> From:	Bernd Brandstetter [SMTP:bb...@fr...]
> Sent:	Wednesday, December 05, 2001 6:50 PM
> To:	dox...@li...
> Subject:	[Doxygen-users] Documenting C code
> 
> Hi,
> 
> I'm relatively new to doxygen and this list, so please forgive me if this 
> is a FAQ:
> 
> While I'm very satisfied with doxygen's output for C++ files I didn't 
> manage to get a reasonable result for C code. In fact, doxygen doesn't 
> document anything besides the file list as long as I don't set 
> EXTRACT_ALL to YES in which case it really documents everything -- 
> including all structures and functions which I don't want to be documented
> 
> and therefore didn't spend a doxygen comment.
> This is independent of the settings of EXTRACT_PRIVATE, EXTRACT_STATIC, 
> HIDE_UNDOC_MEMBERS and OPTIMIZE_OUTPUT_FOR_C.
> 
> Is this a bug, a feature or am I simply doing something wrong?
> (I'm using doxygen-1.12).
> 
> Bye,
> Bernd
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Documenting C code

[Bernd B. <bb...@fr...>]

Hi,

I'm relatively new to doxygen and this list, so please forgive me if this=
=20
is a FAQ:

While I'm very satisfied with doxygen's output for C++ files I didn't=20
manage to get a reasonable result for C code. In fact, doxygen doesn't=20
document anything besides the file list as long as I don't set=20
EXTRACT_ALL to YES in which case it really documents everything --=20
including all structures and functions which I don't want to be documente=
d=20
and therefore didn't spend a doxygen comment.
This is independent of the settings of EXTRACT_PRIVATE, EXTRACT_STATIC,=20
HIDE_UNDOC_MEMBERS and OPTIMIZE_OUTPUT_FOR_C.

Is this a bug, a feature or am I simply doing something wrong?
(I'm using doxygen-1.12).

Bye,
Bernd

[Doxygen-users] RTF problem

[Christopher B. <bre...@ya...>]

So far, we are using Doxygen only for HTML, but there
is some interest in getting RTF output. I enabled the
RTF option but I get a truncated output. The compound
list shows only "defgroup" groups-- no classes. Only
one function is shown (total) and no methods, and a
large table of contents says only "pagenum" for the
locations. So something isn't getting generated. The
HTML version is working perfectly. I'm using Word
2000, but it doesn't complain about the file type (I'm
aware of the caveat that it's optimized for Word 97).
I'd appreciate suggestions.

Christopher Brewster

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

RE: [Doxygen-users] DocJet versus Doxygen for MS IDL?

[Freudenberg, T. <tho...@cy...>]

> Christopher wrote:
> 
> [...]
> For DocJet:
> 
> - Features that work with Dev Studio, including 
> context-sensitive help.

Context-sensitive help works even with doxygen (plus
MSDN Integrator by Kirk Stowell)

Regards,
Thomas

[Doxygen-users] DocJet versus Doxygen for MS IDL?

[Christopher B. <bre...@ya...>]

Jake asks:

    What features/abilities would one gain or loose if
    they did converted from DocJet to Doxygen?

I don't know about your questions regarding MS IDL,
but I did some comparing of Dox with DoxJet. Here were
some aspects of the comparison.

Against Docjet:

- Price: Your prospective employers obviously accepts
paying for DocJet, but they might like freeware too. 

- Design: As a tech writer who cares about design, I
find Doxygen's default design good, and I don't like
DocJet's default (headings too large, text too small).
With Doxygen, a simple change to sans-serif type gives
it another look, also good.

- Platform: DocJet was Windows-only when I checked it
out.

- Output: no printable version with DJ



For DocJet:

- Features that work with Dev Studio, including
context-sensitive help.

- Works with Java.

- (This doesn't apply to your situation.) Can be used
with existing comments in code, with no reformatting.


Those are the main differences I noticed.

Christopher Brewster

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

[Doxygen-users] Possible bug with enums?

[Proskuriakov, I. <Igo...@gs...>]

Hi,
I am using doxygen 1.2.12 for Windows. I have the problem with enums, the
problem is as following:
Simplified example is:
example.hpp
enum {
   active,
   inactive
} State;
 
class Test
{
public:
Test();
State Member;
}
 
 
example.cpp
#include "example.hpp"
 
Test::Test():
member(inactive)
{};

 
configuration file is:
PROJECT_NAME     = "Example Command"
OUTPUT_DIRECTORY = .
GENERATE_LATEX   = NO
GENERATE_MAN     = NO
GENERATE_RTF     = NO
CASE_SENSE_NAMES = YES
INPUT            = example.cpp example.hpp
EXTRACT_ALL            = YES
SOURCE_BROWSER         = YES
 
When producing documentation for Test::Test(), in the list of references,
doxygen puts a wrong link to inactive
href="namespace_3globalScope_4.html#a3a2". The file
namespace_3globalScope_4.html does not exist at all.
 
regards,
Igor Proskuriakov

RE: [Doxygen-users] Member function puzzle

[Glenn M. <gle...@vo...>]

The @class/@fn Doxygen commands followed by a prototype are only need to
be used when the comment is _not_ directly in front of its associated
code item either in the header or the source file. It is useful if you
have to keep your documentation in separate files.=20

(I use it when a class implements a feature that is called by a
function; I expose the function but not the class. The class is where
the developer goes to change how the function works. Moreover, the
function is "generated." Hence, I use @fn to get it to the function
definition.)

Secondly, when @class or @fn is used, it needs to be followed on one
line by the exact prototype. Otherwise it won't be able to match it.

In your case, you don't need the @class. Your comments appear in front
of the owning element. You could safely remove that line (which is a
maintenance hassle anyway.)

If you did use the @class, it would need to be:

/*! @class template <class Return> inline RWTRunnableIOUFunction
Return>::RWTRunnableIOUFunction(void)
  * [above should all be on one line.]
  *  Yes, I'm documented.
  */

Glenn Maxey
Technical Writer
Voyant Technologies, Inc.
1765 West 121st Avenue
Westminster, CO 80234-2301
Tel. +1 303.223.5164
Fax. +1 303.223.5275
gle...@vo...


> -----Original Message-----
> From: Marc Betz [mailto:be...@ro...]
> Sent: Monday, December 03, 2001 2:05 PM
> To: 'dox...@li...'
> Subject: [Doxygen-users] Member function puzzle
>=20
>=20
> The following class
>=20
> /*! @class RWTRunnableIOUFunction<Return>
>  *  Yes, I'm documented.
>  */
> template <class Return>
> class RWTRunnableIOUFunction :
>    public RWRunnable {
>=20
>    public:
>=20
>       /*!=20
>        *  Yes, I'm documented.
>        */
>       RWTRunnableIOUFunction(void);
> };
>=20
> template <class Return>
> inline
> RWTRunnableIOUFunction<Return>::RWTRunnableIOUFunction(void)
> {
>    RW_THREAD_TRACEABLE_TEMPLATE_MEMBER("RWTRunnableIOUFunction_ctor",
> RWTRunnableIOUFunction)
> }
>=20
> results in this error
>=20
> RWTRunnableIOUFunction.h:30: Warning: no matching class=20
> member found for=20
>   RWTRunnableIOUFunction< Return >::RWTRunnableIOUFunction(void)
> Possible candidates:
>   RWTRunnableIOUFunction(void)
>=20
> Does anyone have any experience of this phenomenum, or any=20
> ideas what the
> problem might be?
>=20
> A few additional facts:
> - The actual class has about 15 functions, all of which=20
> generate the same
> type of error.
> - The class does appear in the doxygen output, with no member=20
> functions
> identified.
> - Commenting out the implementation line, with its macro=20
> frunction, does not
> eliminate the problem.
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

[Doxygen-users] Member function puzzle

[Marc B. <be...@ro...>]

The following class

/*! @class RWTRunnableIOUFunction<Return>
 *  Yes, I'm documented.
 */
template <class Return>
class RWTRunnableIOUFunction :
   public RWRunnable {

   public:

      /*! 
       *  Yes, I'm documented.
       */
      RWTRunnableIOUFunction(void);
};

template <class Return>
inline
RWTRunnableIOUFunction<Return>::RWTRunnableIOUFunction(void)
{
   RW_THREAD_TRACEABLE_TEMPLATE_MEMBER("RWTRunnableIOUFunction_ctor",
RWTRunnableIOUFunction)
}

results in this error

RWTRunnableIOUFunction.h:30: Warning: no matching class member found for 
  RWTRunnableIOUFunction< Return >::RWTRunnableIOUFunction(void)
Possible candidates:
  RWTRunnableIOUFunction(void)

Does anyone have any experience of this phenomenum, or any ideas what the
problem might be?

A few additional facts:
- The actual class has about 15 functions, all of which generate the same
type of error.
- The class does appear in the doxygen output, with no member functions
identified.
- Commenting out the implementation line, with its macro frunction, does not
eliminate the problem.

[Doxygen-users] DocJet versus Doxygen for MS IDL?

[Jake K. <jk...@bi...>]

Hi,

I have an interview later this week for a job that currently uses DocJet to document their MS IDL (COM development in C++).  I would
like to suggest maybe converting over to Doxygen, but I don't know what features/abilities they would gain or loose if they did
converted.

So has anyone ever used/compared DocJet from http://www.tall-tree.com/
Specifically to document MS IDL?  The way I understand it, tall-tree uses a filter/remapper to get comments out of the
machine/wizard generated IDL code, but it looks like param names must match the C++ code or DocJet could loose it's place, see:
http://www.tall-tree.com/docjet/Support/IDLRemap/index.html

- What features/abilities would one gain or loose if they did converted from DocJet to Doxygen?
- So is doxygen capable of documenting MS IDL completely?
- Can (how?) does it map the generated COM IDL to developer C++ classes?  (like DocJet Remap?)
- It looks like other have had unanswered question about treating IRecordPtr as an alias for IRecord?  Has anyone solved this?

Thanks for your time,
Jake

[Doxygen-users] why doxygen takes non documented info?(am I doing something wrong?)

[Toni M. <ton...@wa...>]

see the example


/** \defgroup FOO mygroup
	This is my Foo group
	@{
*/

/** \def MY_MACROA this is a defined macro */

#define MY_MACROA(A)	(do something on A)=09

#define MY_MACROB(B)             (do something on B)

#define MY_MACROC(C)	(do something on C)

/** @} */
-------------------------------------------

The ouput generated doc shows the 3 macros while only documented the firs=
t.

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340
-----------------
Tel:937598149
Tel: 699706656
-----------------

Re: [Doxygen-users] TODO Lists in CPP implementation files

[Rod O. <oll...@SE...>]

These produce the same results.  The second has the comment in the function
body.  However, only one ( @fn ) per function will work.


////////////////////////////// 1 /////////////////////////////////////////////

/**
 * @todo change result constants to stcl constants
 */
void sedsystems::grm::simlrm::SimLrmComponent::
setAutoMode( bool autoMode, USTR_String *result)
{
    UDBG_TRACE( "SimLrmComponent::setAutoMode" );

    _autoMode = autoMode;

    *result = sedsystems::sim_fwk::stcl::SUCCESS_RESULT;

}

/////////////////////////////// 2 ////////////////////////////////////////////

void sedsystems::grm::simlrm::SimLrmComponent::
setAutoMode( bool autoMode, USTR_String *result)
{
    UDBG_TRACE( "SimLrmComponent::setAutoMode" );

    _autoMode = autoMode;

/**
 * @fn void sedsystems::grm::simlrm::SimLrmComponent::setAutoMode( bool
autoMode, USTR_String *result)
 * @todo change result constants to stcl constants
 */
    *result = sedsystems::sim_fwk::stcl::SUCCESS_RESULT;

}


"Prikryl,Petr" wrote:

> Hi Victor,
>
> I partly agree with you.  It really would be a bit more useful
> if you could put \todo to the exact point of the code.
> On the other hand, this would require reimplementation
> of the doxygen's mechanism for working with comments.
> Dimitri has some plans for future, but apparently, this is not
> on the top of the preference list now.
>
> Just to avoid some misunderstanding, the \todo's need
> not to be placed in front of the main() function (this was
> written in the context of the given example).  It can be placed
> in front of any function or a member function.  They usually
> tend to have quite short bodies if the architecture of the
> application is good.  This way, the \todo points quite well
> to the place in sources.
>
> In our project, the todo list (if printed) has about 40 pages.
> I don't say if it is good or not.  But definitely, the exact
> placement of these \todo items is not the big problem here.
> Knowing the related class and the method is just enough.
>
> Regards,
>   Petr
>
> > -----Original Message-----
> > From: Wagner, Victor [SMTP:VW...@se...]
> > Sent: Friday, November 30, 2001 3:34 PM
> > To:   Prikryl,Petr
> > Subject:      RE: [Doxygen-users] TODO Lists in CPP implementation files
> >
> > IMO, in order for \todo to be 'really useful' you need to be able to put
> > them anywhere in the file.
> > They are not just notes that "something" needs to be done, they are also
> > markers as to WHERE this "something" needs to be done.
> > in front of main() (most of my files don't have a main()) is about as
> > useful
> > as a bug report "doesn't work".
> >
> > -----Original Message-----
> > From: Prikryl,Petr [mailto:PRI...@sk...]
> > Sent: Friday, 2001 November 30 02:07
> > To: dox...@li...
> > Subject: RE: [Doxygen-users] TODO Lists in CPP implementation files
> >
> >
> > Hi Allan,
> >
> > In your example, your \todo command is used inside
> > the function body.  Doxygen ignores comments inside
> > the function bodies these days.  So, the reason is not
> > because the \todo command is in cpp. It's because
> > it is inside the function body.  Try to put it just in front
> > of your main().
> >
> > Regards,
> >   Petr
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

RE: [Doxygen-users] TODO Lists in CPP implementation files

[Prikryl,Petr <PRI...@sk...>]

Hi Victor, 

I partly agree with you.  It really would be a bit more useful 
if you could put \todo to the exact point of the code.  
On the other hand, this would require reimplementation 
of the doxygen's mechanism for working with comments.
Dimitri has some plans for future, but apparently, this is not 
on the top of the preference list now.

Just to avoid some misunderstanding, the \todo's need
not to be placed in front of the main() function (this was
written in the context of the given example).  It can be placed
in front of any function or a member function.  They usually
tend to have quite short bodies if the architecture of the 
application is good.  This way, the \todo points quite well
to the place in sources.

In our project, the todo list (if printed) has about 40 pages.
I don't say if it is good or not.  But definitely, the exact 
placement of these \todo items is not the big problem here.
Knowing the related class and the method is just enough.

Regards, 
  Petr

> -----Original Message-----
> From:	Wagner, Victor [SMTP:VW...@se...]
> Sent:	Friday, November 30, 2001 3:34 PM
> To:	Prikryl,Petr
> Subject:	RE: [Doxygen-users] TODO Lists in CPP implementation files
> 
> IMO, in order for \todo to be 'really useful' you need to be able to put
> them anywhere in the file.
> They are not just notes that "something" needs to be done, they are also
> markers as to WHERE this "something" needs to be done.
> in front of main() (most of my files don't have a main()) is about as
> useful
> as a bug report "doesn't work".
> 
> -----Original Message-----
> From: Prikryl,Petr [mailto:PRI...@sk...]
> Sent: Friday, 2001 November 30 02:07
> To: dox...@li...
> Subject: RE: [Doxygen-users] TODO Lists in CPP implementation files
> 
> 
> Hi Allan,
> 
> In your example, your \todo command is used inside
> the function body.  Doxygen ignores comments inside
> the function bodies these days.  So, the reason is not
> because the \todo command is in cpp. It's because
> it is inside the function body.  Try to put it just in front
> of your main().
> 
> Regards,
>   Petr

RE: [Doxygen-users] TODO Lists in CPP implementation files

[Allan M. <all...@in...>]

To Rod, Edmund, and Prikyrl:

Moving the \todo items outside of the function body does indeed do the
trick -- thanks!

Rod-- Unfortunately, I wasn't able to generate in-function Todo items using
the \function tag as you described.  I was, however, able to generate
multiple todo's for one function by placing them outside of the function
body.

It's a bummer that you can't drop the todo's inline with the code you're
writing.  Is anyone aware of another tool (other than grep, I guess) that's
good for keeping track of the things you intend to get back to?

A-----


> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf Of Edmund
> Green
> Sent: Friday, November 30, 2001 2:50 AM
> To: Dox...@li...
> Subject: Re: [Doxygen-users] TODO Lists in CPP implementation files
>
>
> re:
>
> > When I generate HTML on this code with Doxygen, the todo list
> contains the
> > first \todo item, but not the one in the .cpp file.  This
> behavior greatly
> > reduces the utility of the Todo feature itself.
>
> I haven't used Doxygen on C++ for a few months now, but I think that it
> doesn't actually look at comments inside function definitions. If you
> put the todo above the main function then it will work.
>
> e.g:
>
>
>  /**!\brief entry point of applications
>    *
>    * some long description
>
>   *\todo DOXYGEN SHOULD PICK THIS UP  <--- move here
>    */
>
> int main (int argc, char* argv)
> {
>   TestClass myTestClass;
>   std::cout << myTestClass.GetValue() << std::endl;
>   std::cout << myTestClass.GetAnotherValue() << std::endl;
> };
>
>
> also re:
>
>  >class TestClass
>  >{
>  >public:
>  >  inline int GetValue() {return mValue;};
>  >  TestClass(){mValue = 42;};
>  >  int GetAnotherValue();
>  >
>  >  /// \todo THIS APPEARS IN THE T0-DO LIST
>  >
>  >protected:
>  >private:
>  >  int mValue;
>  >};
> beware that this causes the todo to link to the documentation for the
> mValue variable (which may or may not have been what you were expecting?)
>
>
> Edmund.
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] TODO Lists in CPP implementation files

[Edmund G. <con...@ya...>]

re:

> When I generate HTML on this code with Doxygen, the todo list contains the
> first \todo item, but not the one in the .cpp file.  This behavior greatly
> reduces the utility of the Todo feature itself.

I haven't used Doxygen on C++ for a few months now, but I think that it 
doesn't actually look at comments inside function definitions. If you 
put the todo above the main function then it will work.

e.g:


 /**!\brief entry point of applications
   *
   * some long description

  *\todo DOXYGEN SHOULD PICK THIS UP  <--- move here
   */

int main (int argc, char* argv)
{
  TestClass myTestClass;
  std::cout << myTestClass.GetValue() << std::endl;
  std::cout << myTestClass.GetAnotherValue() << std::endl; 
};


also re:

 >class TestClass
 >{
 >public:
 >  inline int GetValue() {return mValue;};
 >  TestClass(){mValue = 42;};
 >  int GetAnotherValue();
 >
 >  /// \todo THIS APPEARS IN THE T0-DO LIST
 >
 >protected:
 >private:
 >  int mValue;
 >};
beware that this causes the todo to link to the documentation for the 
mValue variable (which may or may not have been what you were expecting?)


Edmund.

RE: [Doxygen-users] TODO Lists in CPP implementation files

[Prikryl,Petr <PRI...@sk...>]

Hi Allan,

In your example, your \todo command is used inside
the function body.  Doxygen ignores comments inside
the function bodies these days.  So, the reason is not
because the \todo command is in cpp. It's because
it is inside the function body.  Try to put it just in front
of your main().

Regards,
  Petr

> Is there any way to get Doxygen to consider both 
> the .h and .cpp files when
> building its to-do list?  As an example, the code below
> contains \todo commands in both test.h and test.cpp.
>[...]
> int main (int argc, char* argv)
> {
>   TestClass myTestClass;
>   std::cout << myTestClass.GetValue() << std::endl;
>   std::cout << myTestClass.GetAnotherValue() << std::endl;
> 
>   /// \todo DOXYGEN DOESN'T PICK THIS ITEM UP!
> 
> };

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-users] Re: Here are the graphic details

[Christopher B. <bre...@ya...>]

I'm interested to see that another tech writer is
using Doxygen (any others here?). Also I'd like to
know if other people have needed to get detailed about
the formatting effects of the Dox tags.

--- Glenn Maxey <gle...@vo...> wrote:
> So, my advice to you is to:
> 
> (1) Pick a comment style closer to what the
developers are using (as in //!) .

> (3) Use slightly less leading whitespace so it is
easier for the engineers to maintain.

The style shown in my file resulted from trying to be
compatible with existing standards here.  I was 
trying to sell the idea of Doxygen, and I thought it
would go over better if the new parts fit this style.
Most classes and methods in the system aren't part of
the API and are commented with the kind of block shown
in my file: "//" comment characters with 25-space
indents for text. 

For the Dox blocks I used the Javadoc style, since
this is at least a familiar precedent if not a
standard. I wanted it to be distinct from other
commenting. You're right about the reliability of the
comment and tag style; I might change a few things
next time.

I agree with your reservations about the indent but
the programmers have been doing it for years here. For
my work, I have a routine in Word that adds the
comment symbols and indents with correct wrapping, and
reformats it correctly if I change the text. The code
didn't get too much bigger when I replaced the old
comment blocks with Dox (well, it did in a few
places).

> use the @brief tag.
> I do not follow this immediately with the detailed
description (if there
> is one) but instead insert the parameters instead.
When this is output
> in HTML and the prototype gets placed in front of
the brief decription,
> this little trick keeps the very important parameter
descriptions (USED
> DAILY by the engineer) closer to the prototype. 

I try to keep the part before the parameters to just a
modest paragraph (you wouldn't know it from my sample
file). Anything else comes later, which is often when
all that formatting detail is needed.

Christopher Brewster

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1