doxygen-users — List for users of doxygen

[Doxygen-users] RE: including headerfiles inside extern "C"

[Tommy S. P. <TS...@ma...>]

The reason for not having the extern "C" declaration inside the file.h is
that the file.h is considered a standard C header file and is heavily used
in standard C programs on several platforms and compilers.
The problem only appears for #defines - not for e.g. typedefs etc. 

-----Original Message-----
FROM: Catenacci, Onorio
DATE: 01/04/2002 03:41:10
SUBJECT: FW: [Doxygen-users] including headerfiles inside extern "C"
Is there anything preventing you from moving the extern "C" declaration to
the file.h file?  Something like this:
 
file.h: 
/// MEDEF doc
extern "C" {
   #define MYDEF 1
 
//etc.
 
} //end extern "C" declaration
 
fileA.cpp
#include "file.h" //automatically picks up extern "C" because it's in the
header file.
 
In fact I'm more accustomed to seeing the extern "C" in the header file as
opposed to being in the files that include the header.  Of course that
doesn't mean that is more correct--it's just what I'm accustomed to seeing.
 
-- 
Onorio Catenacci

-----Original Message-----
From: Tommy Sanddal Poulsen [mailto:<EMAIL: PROTECTED>] 
Sent: Friday, January 04, 2002 4:42 AM
To: '<EMAIL: PROTECTED>'
Subject: [Doxygen-users] including headerfiles inside extern "C"



Hi, 
I'm currently working on a project implemented in C++ and having C interface
functions declared in separate h-files. The header files are included inside
extern "C" blocks, and this results in multiple define documentation blocks
in the doxygen documentation for the h-file.

The three files file.h, fileA.cpp and fileB.cpp documented using a standard
doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
three blocks documenting the define of the headerfile - I expected only one,
as is the result when the #include's are not embedded inside an extern "C"
block. 

Does anyone have an idea of what to do ? 

file.h: 
        /// MEDEF doc 
        #define MYDEF 1 

fileA.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fA() {} 

fileB.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fB() {} 


- thanks 
>Tommy Poulsen 

Re: [Doxygen-users] including headerfiles inside extern "C"

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

On Fri, Jan 04, 2002 at 10:41:31AM +0100, Tommy Sanddal Poulsen wrote:
> Hi,
> I'm currently working on a project implemented in C++ and having C interface
> functions declared in separate h-files. The header files are included inside
> extern "C" blocks, and this results in multiple define documentation blocks
> in the doxygen documentation for the h-file.
> 
> The three files file.h, fileA.cpp and fileB.cpp documented using a standard
> doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
> three blocks documenting the define of the headerfile - I expected only one,
> as is the result when the #include's are not embedded inside an extern "C"
> block. 
> Does anyone have an idea of what to do ?

Doxygen's preprocessor includes header files verbatimly iff the #include
statement is found inside a curly block, to allow things like:

struct A {
#include "struct_A_elements.h"
};

to be parsed correctly (there is still the issue with line numbering in
the source browser which I have to address some day).

For extern "C" blocks this is of course not desired behaviour, so I'll
adapt the preprocessor for this case.

Regards,
  Dimitri

FW: [Doxygen-users] including headerfiles inside extern "C"

[Catenacci, O. <Ono...@co...>]

Is there anything preventing you from moving the extern "C" declaration to
the file.h file?  Something like this:
 
file.h: 
/// MEDEF doc
extern "C" {
   #define MYDEF 1
 
//etc.
 
} //end extern "C" declaration
 
fileA.cpp
#include "file.h" //automatically picks up extern "C" because it's in the
header file.
 
In fact I'm more accustomed to seeing the extern "C" in the header file as
opposed to being in the files that include the header.  Of course that
doesn't mean that is more correct--it's just what I'm accustomed to seeing.
 
-- 
Onorio Catenacci

-----Original Message-----
From: Tommy Sanddal Poulsen [mailto:TS...@ma...] 
Sent: Friday, January 04, 2002 4:42 AM
To: 'dox...@li...'
Subject: [Doxygen-users] including headerfiles inside extern "C"



Hi, 
I'm currently working on a project implemented in C++ and having C interface
functions declared in separate h-files. The header files are included inside
extern "C" blocks, and this results in multiple define documentation blocks
in the doxygen documentation for the h-file.

The three files file.h, fileA.cpp and fileB.cpp documented using a standard
doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
three blocks documenting the define of the headerfile - I expected only one,
as is the result when the #include's are not embedded inside an extern "C"
block. 

Does anyone have an idea of what to do ? 

file.h: 
        /// MEDEF doc 
        #define MYDEF 1 

fileA.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fA() {} 

fileB.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fB() {} 


- thanks 
>Tommy Poulsen 

Re: [Doxygen-users] XML output tag mismatch

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

On Thu, Jan 03, 2002 at 05:06:38PM -0500, Smith, David wrote:
> Hi,
> 
> 	I'm looking to use Doxygen's XML output to do some basic
> code-metrics, and I was wondering if anyone had run into a tag mismatch.

I think more people would be interested in this (I am :-). 
Any chance your efforts will be open-sourced?

> 	It appears that the XML output generated will contain the mismatched
> tag pair: <exceptions></exception> for documented C++ functions using an
> exception specification (e.g. "void foo() throw ()").

Oops, I'll fix this right away!

Regards,
  Dimitri

[Doxygen-users] including headerfiles inside extern "C"

[Tommy S. P. <TS...@ma...>]

Hi,
I'm currently working on a project implemented in C++ and having C interface
functions declared in separate h-files. The header files are included inside
extern "C" blocks, and this results in multiple define documentation blocks
in the doxygen documentation for the h-file.

The three files file.h, fileA.cpp and fileB.cpp documented using a standard
doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
three blocks documenting the define of the headerfile - I expected only one,
as is the result when the #include's are not embedded inside an extern "C"
block. 
Does anyone have an idea of what to do ?

file.h:
	/// MEDEF doc
	#define MYDEF 1	

fileA.cpp
	extern "C" {
	  #include "file.h"
	}

	void fA() {}

fileB.cpp
	extern "C" {
	  #include "file.h"
	}

	void fB() {}


- thanks 
>Tommy Poulsen

[Doxygen-users] XML output tag mismatch

[Smith, D. <smi...@ty...>]

Hi,

	I'm looking to use Doxygen's XML output to do some basic
code-metrics, and I was wondering if anyone had run into a tag mismatch.

	It appears that the XML output generated will contain the mismatched
tag pair: <exceptions></exception> for documented C++ functions using an
exception specification (e.g. "void foo() throw ()").


	Looking at the "doxygen-1.2.13.tar.gz" source collection (from the
010302 snapshot), the file "src\xmlgen.cpp" contains the lines (starting at
line# 1171)

---<snip>---
  if (md->excpString())
  {
    t << "        <exceptions>";
 
linkifyText(TextGeneratorXMLImpl(t),scopeName,md->name(),md->excpString());
    t << "</exception>" << endl;
  }
---<snip>---

	where a fix for the issue is to change them to

---<snip>---
  if (md->excpString())
  {
    t << "        <exceptions>";
 
linkifyText(TextGeneratorXMLImpl(t),scopeName,md->name(),md->excpString());
    t << "</exceptions>" << endl;
  }
---<snip>---


Many thanks for the excellent tool, and happy ongoing development.

-Dave Smith

RE: [Doxygen-users] Can I get rid of imports when documenting COR BA IDL?

[Kevin W. <KWi...@vi...>]

>> I'd like to get rid of the ' import "filename.idl"; ' 
>> statement being placed at the top of each interface.  
>> There doesn't seem to be a configuration option for 
>> this - is there anything I can do short of modifying 
>> the doxygen source?
>
> You could create a small script (in perl) that processes 
> your output to remove this. I have some Doxygen input 
> filters in Perl that I could share. They could easily 
> be turned into output filters and run as part of a 
> shell script.

Thanks.  I was afraid I would have to do something like this.  I've already
started writing a sed script to remove the stuff I don't want in Doxygen's
output.

I took a look at the Doxygen (current CVS) source code and it appears that
SHOW_INCLUDE_FILES in the config file is supposed to control if "#include"
and "import" directives are inserted in the output, however it doesn't work
for me with Doxygen 1.2.13.

-- Kevin Williams 
   Visionael Corporation 
   kwi...@vi... 

RE: [Doxygen-users] Can I get rid of imports when documenting CORBA IDL?

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

You could create a small script (in perl) that processes your output to
remove this. I have some Doxygen input filters in Perl that I could
share. They could easily be turned into output filters and run as part
of a shell script.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
I'm in the process of documenting a small set of Perl tools for
technical publications. My employer has agreed to let me publish them as
open-source, because we're not necessarily in the business of developing
technical publications tools.=20
=20
The suite of tools helps tech writers create single-source and/or API
documentation. This takes Doxygen output to the next level by
integrating it into a bigger system where output from other sources
(such as FrameMaker) is included.=20
=20
At any rate, one of my files processes all HTML files and "whips them
into shape."=20
=20
As soon as I'm done (~ 1 week), I'll publish them to this list (and
others).

-----Original Message-----
From: Kevin Williams [mailto:KWi...@vi...]
Sent: Thursday, January 03, 2002 9:51 AM
To: 'dox...@li...'
Subject: [Doxygen-users] Can I get rid of imports when documenting CORBA
IDL?



I'd like to get rid of the ' import "filename.idl"; ' statement being
placed at the top of each interface.  There doesn't seem to be a
configuration option for this - is there anything I can do short of
modifying the doxygen source?

-- Kevin Williams=20
   Visionael Corporation=20
   kwi...@vi...=20

[Doxygen-users] Can I get rid of imports when documenting CORBA IDL?

[Kevin W. <KWi...@vi...>]

I'd like to get rid of the ' import "filename.idl"; ' statement being placed
at the top of each interface.  There doesn't seem to be a configuration
option for this - is there anything I can do short of modifying the doxygen
source?

-- Kevin Williams
   Visionael Corporation
   kwi...@vi...

RE: [Doxygen-users] Doxygen Question

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

Hi <br> should work, but--in your case--you could try the 
doxygen syntax for numbered lists like this...

    @COMMENTS:
    -# Comment1...
    -# Comment2...

See you, 
  Petr

P.S. When using HTML tags, prefer lower case with respect to 
the XML future.

Zvi Mizrahi asked...
> [...]
> How we can cause Doxygen to insert Carriage returns that
> exist in the source code comments into the HTML/RTF
> documentation?
> For example, Suppose we have the following code comment :
>
> /*!***************************************************************
>  * .............(other doxygen commands)
>  * @COMMENTS:
>  *       1. Comment1....
>  *       2. Comment2....
>  *
>  *****************************************************************/
> 
> In the configuration file, we have :
>      ALIASES = "COMMENTS=\par General Comments"
> 
> However, in the output we get comment 1 and comment 2
> in the same line:
> 
>     General Comments:
>            Comment 1....Comment 2....
> 
> The two comments appears in the same line since it is
> the same HTML paragraph.
> 
> It is possible to solve this by adding <BR> at the end of
> each line, however, we want to avoid from adding too much
> changing into current source code since we have large
> comment paragraphs.
> 
> Any idea ?
> Your help will be appreciated !

[Doxygen-users] Re: Doxygen-users digest, Vol 1 #231 - 4 msgs

[Jaap S. <s98...@ho...>]

Hi,

thanks for all your help on the Parameter question.

Dimitri: I'll try to make a simple example with only one source file and 
mail it to you tomorrow.

And you were also right about the function not being a real prototype. 
Ofcourse, I only forgot the parameter type (int in your case), in the code 
they are there ofcourse :).

Thanks again

regards,

Jape

>Subject: Re: [Doxygen-users] Question on function-parameters 
>documentation..
>
>On Sun, Dec 30, 2001 at 08:43:21PM +0100, Jaap Suter wrote:
> > Hello,
> >
> > I'm new on the list and I've only been working with Doxygen for four 
>days
> > now. I've searched the documentation and the online mail-archives but
> > coulnd't find any help on this one...
> >
> > What is the difference between:
> >
> > /*!
> >      \brief Some function
> >      \param x Argument X
> > */
> > void Function( x ) {}
> >
> > and
> >
> > /*!
> >      \brief Some function
> > */
> > void Function(
> >                x //!< Argument X
> >              )
> > {}
> >
> > Basically, what is the difference between documenting the parameter in 
>the
> > source-comment, or directly after the declaration of the argument?
>
>There should be no difference in the output (if there is, please send
>a bug report). It is just a matter of taste how you comment the input.
>Both styles have their pros and cons.
>
> > I'd rather use the latter, cause it saves me typing the argument-name 
>twice.
> > However, when I use it all sorts of things dissappear in my generated
> > documentation.
> >
> > With the functions that use the \param method I get the brief comment 
>below
> > it with a 'more...' behind it. With the other method I don't get that. 
>And
> > also the detailed information just seems to be ignored with the latter
> > method. Very confusing.
>
>The confusion is caused by Function not being a real prototype. If you use
>
>/*!
>      \brief Some function
>*/
>void Function(
>                int x //<! Argument x
>              )
>{
>}
>
>then the result should be the same for both cases. Note the "int".
>
>Regards,
>   Dimitri
>
>
>
>--__--__--
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>
>End of Doxygen-users Digest




_________________________________________________________________
Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp.

Re: [Doxygen-users] Question on function-parameters documentation..

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

On Sun, Dec 30, 2001 at 08:43:21PM +0100, Jaap Suter wrote:
> Hello,
> 
> I'm new on the list and I've only been working with Doxygen for four days 
> now. I've searched the documentation and the online mail-archives but 
> coulnd't find any help on this one...
> 
> What is the difference between:
> 
> /*!
>      \brief Some function
>      \param x Argument X
> */
> void Function( x ) {}
> 
> and
> 
> /*!
>      \brief Some function
> */
> void Function(
>                x //!< Argument X
>              )
> {}
> 
> Basically, what is the difference between documenting the parameter in the 
> source-comment, or directly after the declaration of the argument?

There should be no difference in the output (if there is, please send
a bug report). It is just a matter of taste how you comment the input. 
Both styles have their pros and cons.

> I'd rather use the latter, cause it saves me typing the argument-name twice. 
> However, when I use it all sorts of things dissappear in my generated 
> documentation.
> 
> With the functions that use the \param method I get the brief comment below 
> it with a 'more...' behind it. With the other method I don't get that. And 
> also the detailed information just seems to be ignored with the latter 
> method. Very confusing.

The confusion is caused by Function not being a real prototype. If you use

/*!
     \brief Some function
*/
void Function( 
               int x //<! Argument x
             )
{
}

then the result should be the same for both cases. Note the "int".

Regards,
  Dimitri

[Doxygen-users] Including external documentation

[jalal @ g. <ja...@gn...>]

Hi Glenn

Many thanks, that seems to have fixed it.

Putting the filename didn't seem to effect the @class line, but it
stopped the @fn line from working.

Thanx

jalal

FROM: Glenn Maxey
DATE: 12/31/2001=FF07:20:35
SUBJECT: RE:  [Doxygen-users] Including external documentation

Everything may be on one line, but what stands out to me as a possible
error is that your @class and @fn prototypes also list the file name,
AltCtrlx.h. This could certainly contribute to the prototypes not
matching what Doxygen extracts.

Only on your first @file reference do you need that file name.

HTH.

Glenn


> -----Original Message-----
> From: jalal @ gnomedia [mailto:<EMAIL: PROTECTED>]
> Sent: Saturday, December 29, 2001 9:38 AM
> To: <EMAIL: PROTECTED>
> Subject: [Doxygen-users] Including external documentation
>
>
> Hi all
>
> I'm trying to document an existing library (the Windows
> Template Library), of which I have the header files and not
> much else. Nothing is documented in files and I can't change them.
> So, I have an external documentation file. In this I have,
> for example (this is an excerpt):
>
> /** @file AtlCtrlx.h
>     @brief bitmap button, check list view and other controls
> */
>
> /** @class WTL::CMultiPaneStatusBarCtrlImpl AtlCtrlx.h
>     @brief Class implementing a MultiPane status bar control
>     @see WTL::CMultiPaneStatusBarCtrl
> */
>
> /** @fn template<class T, class TBase =3D CStatusBarCtrl> BOOL
> WTL::CMultiPaneStatusBarCtrlImpl< T, TBase >::SetPanes(int*
> pPanes, int nPanes, bool bSetText =3D true) AtlCtrlx.h
>  *  @brief Sets the panes to values
>  *
>  *  Further instruction will go here.
>  */                                  
>
> Everything works very well, except for the @fn tag, which
> gives me '... not defined' error. I've tried every combination I can
> think of, but no way will Doxygen recognize it. (and yes,
> everything is on one line, I'm not sure what the emailer is
> going to do with it.)
>
> Any ideas?
>
> regards
> jalal
>
>

RE: [Doxygen-users] Question on function-parameters documentation..

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

Although I can certainly see the merits of not having to type the
argument name twice, you will be better off in the long run if you do
put it into a comment block.

I haven't fully played with the inline comments. What little I have done
brought to light an interesting facet. Doxygen does not group the inline
comments into a comment block. Specifically, when I used the //! style
for the headings of my files, Doxygen starting pulling off comments from
the file heading and putting them on the first valid code item it found,
such as a #define. I now have input filters that turn all //! comments
into /** ...**/ comment blocks before piping it through Doxygen.

In your case, if the description to a parameter went more than one line
(which could happen at my company where the developers are restricted in
line lengths), your parameter comment could get split up and associated
with incorrect elements.

Another aspect to consider that only a tech writer like me would care
about, the second option doesn't give a lot of consistency in the
output, particularly when you start adding more than the @brief
description, such as @return, @retval, @bug, @ingroup, and a detailed
description.

I created templates that I placed in the code (or the developer used)
that specifies the order in which information is displayed.

/** @brief _TBD_
 **=20
 ** @param _TBD_
 ** @param _TBD_
 **
 ** @return _TBD_
 **
 ** _TBD_ [Detailed Description]
 **
 ** @bug None.
 ** @ingroup _TBD_
 **/

I would fill in as much of the _TBD_ stuff as I could. Anything I didn't
know, I left for the developers to flesh out.

My template design purposely places the @param and @return/@retval in
between the @brief and the detailed description. It provides a much more
usable output, because then the syntax is only separated from the @param
by a @brief statement and not some long detailed description. Also, our
developers made a strong case that all of these items should be present
in the template with a "None" if it didn't apply; that way, they
wouldn't forget it. (I have an input filter that turns @bug into @lim
for a user-defined "Limitations and Caveats" that does often get filled
in.)

Using a comment block provides another advantage in that 95% of the
information that would need to be extracted could be found there. This
meant that the developers could add all sorts of normal // comments
anywhere in their code to clarify things that only they would care about
in the implementation.=20

HTH,
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: Jaap Suter [mailto:s98...@ho...]
> Sent: Sunday, December 30, 2001 12:43 PM
> To: dox...@li...
> Subject: [Doxygen-users] Question on function-parameters=20
> documentation..
>=20
>=20
> Hello,
>=20
> I'm new on the list and I've only been working with Doxygen=20
> for four days=20
> now. I've searched the documentation and the online mail-archives but=20
> coulnd't find any help on this one...
>=20
> What is the difference between:
>=20
> /*!
>      \brief Some function
>      \param x Argument X
> */
> void Function( x ) {}
>=20
> and
>=20
> /*!
>      \brief Some function
> */
> void Function(
>                x //!< Argument X
>              )
> {}
>=20
> Basically, what is the difference between documenting the=20
> parameter in the=20
> source-comment, or directly after the declaration of the argument?
> I'd rather use the latter, cause it saves me typing the=20
> argument-name twice.=20
> However, when I use it all sorts of things dissappear in my generated=20
> documentation.
>=20
> With the functions that use the \param method I get the brief=20
> comment below=20
> it with a 'more...' behind it. With the other method I don't=20
> get that. And=20
> also the detailed information just seems to be ignored with=20
> the latter=20
> method. Very confusing.
>=20
> I could provide you with a short example should that be neccesary.
>=20
> Thanks for your help,
>=20
> Jaap Suter
>=20
>=20
> _________________________________________________________________
> Chat on line met vrienden en probeer MSN Messenger uit:=20
> http://messenger.msn.nl
>=20
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

RE: [Doxygen-users] Including external documentation

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

Everything may be on one line, but what stands out to me as a possible
error is that your @class and @fn prototypes also list the file name,
AltCtrlx.h. This could certainly contribute to the prototypes not
matching what Doxygen extracts.

Only on your first @file reference do you need that file name.

HTH.

Glenn

> -----Original Message-----
> From: jalal @ gnomedia [mailto:ja...@gn...]
> Sent: Saturday, December 29, 2001 9:38 AM
> To: dox...@li...
> Subject: [Doxygen-users] Including external documentation
>=20
>=20
> Hi all
>=20
> I'm trying to document an existing library (the Windows=20
> Template Library), of which I have the header files and not=20
> much else. Nothing is documented in files and I can't change them.
> So, I have an external documentation file. In this I have,=20
> for example (this is an excerpt):
>=20
> /** @file AtlCtrlx.h
>     @brief bitmap button, check list view and other controls
> */
>=20
> /** @class WTL::CMultiPaneStatusBarCtrlImpl AtlCtrlx.h
>     @brief Class implementing a MultiPane status bar control
>     @see WTL::CMultiPaneStatusBarCtrl
> */
>=20
> /** @fn template<class T, class TBase =3D CStatusBarCtrl> BOOL=20
> WTL::CMultiPaneStatusBarCtrlImpl< T, TBase >::SetPanes(int*=20
> pPanes, int nPanes, bool bSetText =3D true) AtlCtrlx.h
>  *  @brief Sets the panes to values
>  *=20
>  *  Further instruction will go here.
>  */                                  =20
>=20
> Everything works very well, except for the @fn tag, which=20
> gives me '... not defined' error. I've tried every combination I can=20
> think of, but no way will Doxygen recognize it. (and yes,=20
> everything is on one line, I'm not sure what the emailer is=20
> going to do with it.)
>=20
> Any ideas?
>=20
> regards
> jalal
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

[Doxygen-users] Question on function-parameters documentation..

[Jaap S. <s98...@ho...>]

Hello,

I'm new on the list and I've only been working with Doxygen for four days 
now. I've searched the documentation and the online mail-archives but 
coulnd't find any help on this one...

What is the difference between:

/*!
     \brief Some function
     \param x Argument X
*/
void Function( x ) {}

and

/*!
     \brief Some function
*/
void Function(
               x //!< Argument X
             )
{}

Basically, what is the difference between documenting the parameter in the 
source-comment, or directly after the declaration of the argument?
I'd rather use the latter, cause it saves me typing the argument-name twice. 
However, when I use it all sorts of things dissappear in my generated 
documentation.

With the functions that use the \param method I get the brief comment below 
it with a 'more...' behind it. With the other method I don't get that. And 
also the detailed information just seems to be ignored with the latter 
method. Very confusing.

I could provide you with a short example should that be neccesary.

Thanks for your help,

Jaap Suter


_________________________________________________________________
Chat on line met vrienden en probeer MSN Messenger uit: 
http://messenger.msn.nl

Re: [Doxygen-users] [Fwd: Doxygen Question]

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

On Sun, Dec 30, 2001 at 09:39:58AM +0200, Zvi Mizrahi wrote:
> Trying to forward again this question to teh mailing list.
> Thanks
> zv...@ga...
> www.marvell.com
> 

> X-Mozilla-Status2: 00000000
> Date: Sun, 23 Dec 2001 09:16:34 +0200
> From: Zvi Mizrahi <zv...@ga...>
> X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
> X-Accept-Language: en
> To: dox...@li...
> Subject: Doxygen Question
> 
> Hi,
> We have enjoyed very much from evaluating the Doxygen
> tool for our code.  We have a question:
> 
> How we can cause Doxygen to insert Carriage returns that
> exist in the source code comments into the HTML/RTF
> documentation?
> 
> For example, Suppose we have the following code comment :
> 
> 
> /*!***************************************************************
>  * .............(other doxygen commands)
>  * @COMMENTS:
>  *       1. Comment1....
>  *       2. Comment2....
>  *
>  *****************************************************************/
> 
> In the configuration file, we have :
>      ALIASES = "COMMENTS=\par General Comments"
> 
> However, in the output we get comment 1 and comment 2
> in the same line:
> 
>     General Comments:
>            Comment 1....Comment 2....
> 
> The two comments appears in the same line since it is
> the same HTML paragraph.

The documentation you type in the comments works mostly as text
in HTML (i.e. text and markup commands), so this is not a bug!
Use
  -# Comment1
  -# Comment2

To get the ordered list you want (without even having to do the
counting yourself). This can of course also be read in the 
documentation (which is probably why nobody answered your question)...

Regards,
  Dimitri

[Doxygen-users] [Fwd: Doxygen Question]

[Zvi M. <zv...@ga...>]

Trying to forward again this question to teh mailing list.
Thanks
zv...@ga...
www.marvell.com

[Doxygen-users] Doxygen-1.2.13 in CVS

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

Hi,

I've just committed release 1.2.13 to CVS, and will update the download page
tomorrow. Here is the changelog since last release:
---------------------------------------------------------------------------
+ BUG: STRIP_FROM_PATH now works for windows style paths as well.
       Thanks to Joël Conraud for the patch.
+ ADD: New option INLINE_INHERITED_MEMB which can be enabled to include all
       directly and indirectly inherited members inside the
       documentation of a class as if they were real members (inspired by
       a patch sent by Ted Drain).
+ ADD: Thanks to Harry Kalogirou doxygen now has support for output in
       the Greek language.
+ BUG: For functions whose declaration was grouped and whose definition
       contained a documentation block with a todo/test/bug item,
       the item did not appear in the todo/test/bug list.
+ BUG: In the source browser output, the "=" in variable initializers
       was replaced by "==".
+ ADD: Added option EXTRACT_LOCAL_CLASSES which can be used to show
       or hide classes and struct defined in source files.
+ BUG: Fixed parse problem for typedefs of function pointers returning
       a template instance.
+ ADD: Thanks to an install script written by David Greig, the windows
       version of doxygen now comes with a windows installer based on
       Jordan Russell's Inno Setup.
+ CHG: Reorganized the XML parser. It is now structured as a library,
       a header file, and a test application. See addon/doxmlparser for
       details.
+ BUG: Fixed bug in parsing method pointer function arguments of the
       form "void f(void (C::*m)() const)"
---------------------------------------------------------------------------
Enjoy,
  Dimitri

[Doxygen-users] Including external documentation

[jalal @ g. <ja...@gn...>]

Hi all

I'm trying to document an existing library (the Windows Template Library), of which I have the header files and not much else. Nothing is documented in files and I can't change them.
So, I have an external documentation file. In this I have, for example (this is an excerpt):

/** @file AtlCtrlx.h
    @brief bitmap button, check list view and other controls
*/

/** @class WTL::CMultiPaneStatusBarCtrlImpl AtlCtrlx.h
    @brief Class implementing a MultiPane status bar control
    @see WTL::CMultiPaneStatusBarCtrl
*/

/** @fn template<class T, class TBase = CStatusBarCtrl> BOOL WTL::CMultiPaneStatusBarCtrlImpl< T, TBase >::SetPanes(int* pPanes, int nPanes, bool bSetText = true) AtlCtrlx.h
 *  @brief Sets the panes to values
 * 
 *  Further instruction will go here.
 */                                   

Everything works very well, except for the @fn tag, which 
gives me '... not defined' error. I've tried every combination I can 
think of, but no way will Doxygen recognize it. (and yes, 
everything is on one line, I'm not sure what the emailer is going to do with it.)

Any ideas?

regards
jalal

Re: [Doxygen-users] How to search archives of this list?

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

On Fri, Dec 28, 2001 at 07:37:56PM -0500, Phil Edwards wrote:
> The sourceforge page links to the geocrawler page.  The geocrawler page
> doesn't have anything on it about searching the list archives.  Annoyingly,
> if you click on the "up one level" link, to the page of "sourceforge
> lists handled at geocrawler," it says "Choose a list and you can search
> from there."  But I can't find a search form /anywhere/.
> 
> Help?

Searching via geocrawler is broken and will not be fixed. The people at
sourceforge are working on a new mailing list archiver, which will hopefully
be active soon, so please bare with us some more...

Regards,
  Dimitri

[Doxygen-users] How to search archives of this list?

[Phil E. <ped...@di...>]

The sourceforge page links to the geocrawler page.  The geocrawler page
doesn't have anything on it about searching the list archives.  Annoyingly,
if you click on the "up one level" link, to the page of "sourceforge
lists handled at geocrawler," it says "Choose a list and you can search
from there."  But I can't find a search form /anywhere/.

Help?


-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

[Doxygen-users] User defined keywords & Comments within method definition

[zrb <pa...@op...>]

Hi,

    I would like to know whether there is any way to make understand user
defined keywords.  We right now have # defined some key macros which give a
better meaning to our code.  Like bizClass (for class), object: (for
private), user: (for public) etc.  We would like doxygen to document these
in a standard template that we define.

    Also we find that doxygen conveniently skips the comments within functin
bodies.  We would like it to parse it and generate pseudo code, so that our
business analyst can verify it.

    Thanks in advance.

Regards

parthi

[Doxygen-users] Doxygen Question

[Zvi M. <zv...@ga...>]

Hi,
We have enjoyed very much from evaluating the Doxygen
tool for our code.  We have a question:

How we can cause Doxygen to insert Carriage returns that
exist in the source code comments into the HTML/RTF
documentation?

For example, Suppose we have the following code comment :


/*!***************************************************************
 * .............(other doxygen commands)
 * @COMMENTS:
 *       1. Comment1....
 *       2. Comment2....
 *
 *****************************************************************/

In the configuration file, we have :
     ALIASES = "COMMENTS=\par General Comments"

However, in the output we get comment 1 and comment 2
in the same line:

    General Comments:
           Comment 1....Comment 2....

The two comments appears in the same line since it is
the same HTML paragraph.

It is possible to solve this by adding <BR> at the end of
each line, however, we want to avoid from adding too much
changing into current source code since we have large
comment paragraphs.

Any idea ?
Your help will be appreciated !
Thanks!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zvika Mizrahi
Galileo Technology Ltd - a Marvell Company
Tel : +972-4-9999555 ext. 1177
Fax : +972-4-9999334
zv...@ga...
www.marvell.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Doxygen-users] typedef struct, and searching archive

[Rob B <row...@ya...>]

Hi All:

I am just starting to use doxygen for the first time,
and I have a question.  I tried to search the mail
archive (to see if the question was asked before), I
went to:

http://www.geocrawler.com/lists/3/SourceForge/11668/0/

to see the archive, but there was no search button.

My question is:

I am using a C compiler (not C++).  Oftentimes, to
reduce typing, I do the following:

/// myStruct documentation
typedef struct myStruct_s
{
  struct body
} myStruct_t;

Then, in another structure, I may reference the
original structure as myStruct_t instead of "struct
myStruct_s", such as:

/// struct2 documentation
struct struct2
{
  myStruct_t structMember;
}

When the documentation is generated, on the page for
struct2, I would like a cross-reference to myStruct_t
when the structMember is documented.  However, doxygen
is only generating documentation for struct
myStruct_s, and not myStruct_t.

How to I get the documentation to cross-reference
myStruct_t, and link it to the documentation page for
myStruct_s?

Thank you,

Rob



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