doxygen-users — List for users of doxygen

Re: [Doxygen-users] \todo and the likes...

[Geoff D. <gef...@di...>]

Jacob,
The todo list should be in the related pages section... html/pages.html
(link on the far right).

If it's not there then you do indeed have a prob.

Gef :]

On Tue, 20 Nov 2001 08:02:04 +0100
"Jakob Pagter" <Jak...@cr...> wrote:

> Hi!
> 
> I'm a newbie doxygen user who is trying to document a project using
> doxygen. Doing it pretty naively/straightforward, I have gotten the basics
> to work, i.e., \author, placing of dosygen comments etc. Still, there are a
> few things that does work (even though I actually read the manual...:)
> 
>      o \todo, \test, \bug - despite setting "GENERATE_TODOLIST = YES" etc.,
> todo's etc. are nowhere to be found in the generated documentation.
> 
>      o \date - even though I use it, no dates appear anywhere.
> 
> Example code:
> 
>   /**
>    * Imports types and elements from a file.
>    *
>    * The operation should be part of a transaction which is rolled back if
> anything goes wrong.
>    * If the file contain application type or data elements already present
> in DB, the method will fail.
>    *
>    * @author Me
>    * @date Nov 2001.
>    *
>    * @param T A transaction.
>    * @param fileName The fileName to be read.
>    *
>    * @throw import_exception If something goes wrong.
>    *
>    * @return A vector of names of the types that were imported
>    *
>    * @todo Testing 1-2
>    *
>    * @test Do this.
>    * @test Do that.
>    *
>    * @bug Dummy - nothing is really wrong.
>    */
>   vector<string> importElements(Transaction&, string&);
> 
> TIA
> 
> -- Jakob
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users


--
I represent a sardine!!

[Doxygen-users] \todo and the likes...

[Jakob P. <Jak...@cr...>]

Hi!

I'm a newbie doxygen user who is trying to document a project using
doxygen. Doing it pretty naively/straightforward, I have gotten the basics
to work, i.e., \author, placing of dosygen comments etc. Still, there are a
few things that does work (even though I actually read the manual...:)

     o \todo, \test, \bug - despite setting "GENERATE_TODOLIST = YES" etc.,
todo's etc. are nowhere to be found in the generated documentation.

     o \date - even though I use it, no dates appear anywhere.

Example code:

  /**
   * Imports types and elements from a file.
   *
   * The operation should be part of a transaction which is rolled back if
anything goes wrong.
   * If the file contain application type or data elements already present
in DB, the method will fail.
   *
   * @author Me
   * @date Nov 2001.
   *
   * @param T A transaction.
   * @param fileName The fileName to be read.
   *
   * @throw import_exception If something goes wrong.
   *
   * @return A vector of names of the types that were imported
   *
   * @todo Testing 1-2
   *
   * @test Do this.
   * @test Do that.
   *
   * @bug Dummy - nothing is really wrong.
   */
  vector<string> importElements(Transaction&, string&);

TIA

-- Jakob

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Dean P. <po...@ds...>]

<snip>

Let me add a big ditto to most of this.  Doxygen is great, but I find it =

is almost, but not quite there for documenting C code.

>2) * hide Macro definitions body. ( and document them like functions )

You can hide macro body with @hideinitializer.  It would be good to be ab=
le to add =

information about the type of macro parameters and expected returns where=
 =

relevant.  Also it would be nice to be able to abstract the fact that a =

macro is a macro and not a function, as sometimes you want to switch =

between functions and macros.

I also tend to want to give the full definition of a struct when =

documenting it instead of the current approach that just lists out the =

members.

I also really want to be able to generate a single HTML/man page per func=
tion =

with a big alphabetic index.  Haven't been able to find a good way to do =

this.
-- =

Dean Povey,              |em: dp...@we...|  JCSI: Java security =
toolkit
Senior S/W Developer     |ph:  +61 7 3864 5120    | uPKI: Embedded/C PKI =
toolkit
Wedgetail Communications |fax: +61 7 3864 1282    |       uASN.1: ASN.1 C=
ompiler
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Sig=
natures =

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Carlo W. <ca...@al...>]

On Tue, Nov 20, 2001 at 04:37:37AM +0100, Toni Moreno Giménez wrote:
> 3) (Disable File List Section)
> 
> If you are documenting a like "Object Oriented C code" is common use a couple 
> of source code files for each "object." 
> 
> myobject.c
> myobject.h 
> 
> But the final library usually have and unique header to include.
> By example mi lib has while developing the first release aprox 25 headers
> 
> but only one is needed to use the lib.

Same thing here, at least I should be able to hide heaader files
that I explicitely NOT documented (didn't add a \file in).
Doxygen now generates this page:

Here is a list of all documented files with brief descriptions:
libcw/bfd.h [code]
libcw/buf2str.h [code]			Definition of utility class buf2str
libcw/char2str.h [code]			Definition of utility class char2str
libcw/class_alloc.h [code]
libcw/class_channel.h [code]
libcw/class_channel_set.h [code]
libcw/class_continued_channel.h [code]
libcw/class_debug.h [code]
libcw/class_debug_string.h [code]
libcw/class_fatal_channel.h [code]
libcw/class_location.h [code]
libcw/class_marker.h [code]
libcw/control_flag.h [code]
libcw/core_dump.h [code]
libcw/cwprint.h [code]			Definition of the utilities cwprint and cwprint_using
libcw/debug.h [code]			This is the main header file of libcwd
libcw/debug_config.h [code]
libcw/debugmalloc.h [code]
libcw/demangle.h [code]
libcw/enum_memblk_types.h [code]
libcw/lockable_auto_ptr.h [code]
libcw/macro_ForAllDebugChannels.h [code]
libcw/macro_ForAllDebugObjects.h [code]
libcw/macro_Libcwd_macros.h [code]
libcw/max_label_len.h [code]
libcw/pc_mangled_function_name.h [code]
libcw/private_allocator.h [code]
libcw/private_assert.h [code]
libcw/private_debug_stack.h [code]
libcw/private_internal_string.h [code]
libcw/private_internal_stringstream.h [code]
libcw/private_internal_vector.h [code]
libcw/private_set_alloc_checking.h [code]
libcw/private_threading.h [code]
libcw/private_TSD.h [code]
libcw/strerrno.h [code]
libcw/sysd.h [code]
libcw/type_info.h [code]

while I only want the four documented ones to appear.
The user NEVER has to #include any other.

-- 
Carlo Wood <ca...@al...>

[Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

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

Well , First we should define what is "easy" and "fast readable" Manual.
I'm now using doxigen for my C Library , and I want to achieve a Referenc=
e=20
manual  that looks like  GLib and Gtk+  API reference Manual(=20
http://www.gtk.org/api/ )

I was been  testing diferent doxigen features, and I think it is really=20
posible to do a nice API doc like Glib uses ( for C users)

But I have detected some leaks in current features, in order  to do a per=
fect=20
API C reference manual.

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

1) * hide Enum Values.

2) * hide Macro definitions body. ( and document them like functions )


3) (Disable File List Section)

If you are documenting a like "Object Oriented C code" is common use a co=
uple=20
of source code files for each "object."=20

myobject.c
myobject.h=20

But the final library usually have and unique header to include.
By example mi lib has while developing the first release aprox 25 headers

but only one is needed to use the lib.

#include <mylibheader.h>

and mylibheader.h  contains the actual header files.

#include <object1.h>
#include <object2.h>
.....
#include <object3.h>

I want to say that I don't need a "File List" Section in the HTML Output =
 ,=20
and I can't disable it  now.

4)  Add an arbitrary header file per group

Something like..

/** @addgroup myobject=20
*	@mygroupheader  mylibheader.h <<------=20
*	@{
*/

Well I'm making "Object" documentation one per group
and the grouping feature runs OK. but  I can't specify what's header's fi=
le=20
needs this group.

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

There are some other little things that can be added , but the most impor=
tat=20
are the before explained. ( 1 and 2 for both ,C and C++ API reference man=
uals)

About other features, ALL are running OK and the feel and look of my manu=
al=20
is olmost the same as GLib and Gtk manuals. ( only changing colors of=20
course..).

I can search for some other features , If any developer ask me.

Lots of Thanks.

--=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
-----------------

[Doxygen-users] Feature request

[Carlo W. <ca...@al...>]

Dunno if this is the best list, but I think Dimitri is reading
this list as well, so here it goes:

I am in desperate need for a little better namespace support
as follows: I'd like to be able to define (inline in the
source code and as default in the config file) a default
namespace for both input (links) and output (functions,
classes, variables etc).

The default namespace should have the following precedence:
Input:
1) Whatever is defined inline in the source code
   (with a new command, for example: \default_namespace_in libcw::debug)
or, of that is not available:
2) The current namespace
Output:
1) Whatever is defined inline in the source code
   (with a new command, for example: \default_namespace_out libcw::debug)
or, of that is not available:
2) Whatever is defined in the config file.

Example, suppose the default output namespace in the
config file is set to "aaa::bbb" then instead of printing
"aaa::bbb::ccc::ddd" doxygen should print "ccc::ddd".
Unless explicitely a different output namespace is set:

/**
 * \default_namespace_out aaa
 * Click here \ref aaa::bbb::ccc::func()
 */

Should output "bbb::ccc::func()".

The input namespace would make it easier to write links,
for example when the default namespace is "aaa::bbb", then
one shouldn't need to specify that:

namespace aaa {
  namespace bbb {
    /**
     * \default_namespace_out aaa
     * Click here \ref ccc::func()
     */
...

would look for "ccc::func()" inside namespace aaa::bbb (because that
is the current namespace), find it and then print "bbb::ccc::func()"
because the default output namespace is set to "aaa".

As it is now I have constantly tell doxygen where to find variables
and classes and then use a cubersome /link construct because I don't
want it to be printed like that...  For example:

/** This is a \link libcw::debug::class_ct::example() class_ct::example() \endlink. */

I'd rather just write:

/** This is a class_ct::example(). */

Imho a good policy would be to automatically add a link for everything (that is
found in the default namespace(s)) that contains a :: or (...), and not in
other cases; in that case one would have to add explicitely \ref.

For example:

/** This is automatically linked to: Foo::foo, this too: func().
 * But here I need to add explicitely a reference: \ref foobar. */

Having a namespace called 'debug' and one called 'channels',
I am getting nuts writing %debug %channels alllllll the time.
I'd rather have to explicitely tell doxygen when a simple
english word has to be resolved as something that can be referenced.

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

[Carlo W. <ca...@al...>]

On Mon, Nov 19, 2001 at 06:27:04PM +0100, Toni Moreno Giménez wrote:
> library users need  ONLY. to know the label of each format type.

I agree.  The nature of enums is such that in general the value
is 'internal', and showing it to a user messes up the cleanness
of the documentation as it is not relevant.
In SOME cases it is important to know the values, when enums
are correlated somehow, but that is in general Bad Programming
then (and constant integers should have been used instead).

The default should be NOT to show enum values.  An option
*per* enum could be added to show it.  For example:

/**
 * \show_values
 */
enum foo {
...

Same thing for macro functions, in general the definition of
the macro should be hidden and only shown when explicitely
requested:

/**
 * \show_definition
 */
#define FOO(x) (x * x * x - 2 * x + 3)

-- 
Carlo Wood <ca...@al...>

[Doxygen-users] Doxybar 0.12 && Doxygen 1.2.12 exclude problem

[<vel...@te...>]

When I use DoxyBar Build in Doxyfile is added
INPUT += ... \
.\moc\moc_className.cpp files
...

How can I exclude the moc files that are used in the project?

My template Doxygen file conteints :
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
INPUT                  = dox
FILE_PATTERNS          = *.dox
RECURSIVE              = NO
EXCLUDE                =
                         ^^^^^^^^^ // DON'T WORK I was try *moc* moc_ *moc_*
etc.
EXCLUDE_PATTERNS       = moc_*.cpp
                         ^^^^^^^^^ // DON'T WORK I was try *moc* moc_ *moc_*
etc.
EXAMPLE_PATH           = . \
                         xpm
EXAMPLE_RECURSIVE      = NO
EXAMPLE_PATTERNS       = *.xpm \
                       = *.cache
IMAGE_PATH             = png \
                         xpm \
                         snapshots
INPUT_FILTER           =
FILTER_SOURCE_FILES    = NO
...
# Added by DoxyBar
INPUT += ... \
.\moc\moc_className.cpp files
...

Maybe somebody knows the solution of my problem. ?!?

Cheers,
VV

________________________________________________________________

                       Vélizar VESSELINOV

  Chef de projet Informatique  ~     Computer Project Manager

                Telephone : +33.(0)4.67.59.30.47
             E-mail : vel...@te...

 Techsia S.A.
 Cap Alpha - Avenue de l'Europe, Clapiers
 34940 Montpellier Cedex 9               http://www.techsia.com
 France                              Fax : +33.(0)4.67.59.36.19
________________________________________________________________

    Les données maîtrisées     ~       The end of doubt

[Doxygen-users] Formulas in html. and enums in latex

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

Can I change the default size of the formulas? The Html output size , is=20
realy small...

I have used the Option ENUM_VALUES_PER_LINE   =3D 1 , and the html output=
 is OK.
but the latex ( well pdf indeed) is not 1 line sorted.=20


Lots of thanks.

(When fixed these little troubles in my doc I 'll send  a link  where to =
find=20
it , to see how bad is my library.... XDDD ).


--=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

Re: [Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

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

> >C) Enums:
> >  I asign a value to all "labels" in my enums.
> >
> >         Example:
> >
> >         enum MyEnum {
> >                 MYVAL_0 =3D 0,
> >                 MYVAL_1 =3D 3,
> >                 MYVAL_2 =3D 0x08,
> >         }
> >
> >The doxigen outputs , maintains the values, but I would like only show=
ing
> >
> >         enum MyEnum {
> >                 MYVAL_0,
> >                 MYVAL_1,
> >                 MYVAL_2,
> >         }
> >
> I'm not sure why you think you need the features, but
> A) turn of include source... we generate two versions, for users and fo=
r
> developers... users don't get the source
> C) knowing the name of an enum withOUT it's value is barely useful whil=
e
> debugging.

See yourself.


typedef enum  GsDataFormat {=20
  GSDATAFORMAT_SI8 =3D=20
GSDATAFORMAT_SET_INT(FORMAT_SIGNED,FORMAT_BYTEORDER_NE,1),=20
  GSDATAFORMAT_SI16 =3D=20
GSDATAFORMAT_SET_INT (FORMAT_SIGNED, FORMAT_BYTEORDER_HE, 2),=20
  GSDATAFORMAT_SI16_LE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_SIGNED, FORMAT_BYTEORDER_LE, 2),=20
  GSDATAFORMAT_SI16_BE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_SIGNED, FORMAT_BYTEORDER_BE, 2),=20
  GSDATAFORMAT_SI32 =3D=20
GSDATAFORMAT_SET_INT (FORMAT_SIGNED, FORMAT_BYTEORDER_HE, 4) ,=20
  GSDATAFORMAT_SI32_BE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_SIGNED, FORMAT_BYTEORDER_BE, 4),=20
  GSDATAFORMAT_UI8 =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_NE, 1),=20
  GSDATAFORMAT_UI16 =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_HE, 2),=20
  GSDATAFORMAT_UI16_LE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_LE, 2),=20
  GSDATAFORMAT_UI16_BE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_BE, 2),=20
  GSDATAFORMAT_UI32 =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_HE, 4),=20
  GSDATAFORMAT_UI32_LE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_LE, 4),=20
  GSDATAFORMAT_UI32_BE =3D=20
GSDATAFORMAT_SET_INT (FORMAT_UNSIGNED, FORMAT_BYTEORDER_BE, 4),=20
  GSDATAFORMAT_NF32 =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_HE, 4),=20
  GSDATAFORMAT_NF32_LE =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_LE, 4),=20
  GSDATAFORMAT_NF32_BE =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_BE, 4),=20
  GSDATAFORMAT_NF64 =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_HE, 8),=20
  GSDATAFORMAT_NF64_LE =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_LE, 8),=20
  GSDATAFORMAT_NF64_BE =3D=20
GSDATAFORMAT_SET_FP (FORMAT_FPNORM, FORMAT_BYTEORDER_BE, 8)=20
 }

where GSDATAFORMAT_SET_{INT.FP} () is a macro that defines data types. on=
ly=20
used in development of the library.

do You really think  can be usefull maintain values?

 library users need  ONLY. to know the label of each format type.

typedef enum  GsDataFormat {=20
  GSDATAFORMAT_SI8 ,	/** and some other comment about..*
  GSDATAFORMAT_SI16,
  GSDATAFORMAT_SI16_LE,
  GSDATAFORMAT_SI16_BE,=20
  GSDATAFORMAT_SI32,
  GSDATAFORMAT_SI32_BE,
  GSDATAFORMAT_UI8,
  GSDATAFORMAT_UI16,
  GSDATAFORMAT_UI16_LE,
  GSDATAFORMAT_UI16_BE,
  GSDATAFORMAT_UI32,
  GSDATAFORMAT_UI32_LE,
  GSDATAFORMAT_UI32_BE,
  GSDATAFORMAT_NF32,
  GSDATAFORMAT_NF32_LE,
  GSDATAFORMAT_NF32_BE,=20
  GSDATAFORMAT_NF64,
  GSDATAFORMAT_NF64_LE,
  GSDATAFORMAT_NF64_BE,=20
 }

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

ABOUT DEFINES

this is the output of a Macro generated by doxygen.

 #define GS_UI32_TO_SI32( __v )    ( (gint32) ((__v)+GS_DC_INT32))=20
	Returns: This macro return the (gint32) converted value=20

How can I show only ..?:

#define GS_UI32_TO_SI32( __v ) =20
	Returns: This macro return the (gint32) converted value=20



Thanks.

=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

[Doxygen-users] Doxygen-1.2.12 in CVS

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

Hi,

I've just committed the new release to CVS. Here's the changelog:
-----------------------------------------------------------------------------
+ ADD: Included patch by Erik Zeek to add EOL translation to the 
       config file output.
+ ADD: Doxygen now searches the current directory for sources if
       the INPUT and FILE_PATTERNS are empty (thanks to Johan Eriksson
       for ideas and code)
+ ADD: Added update for Croatian by Boris Bralo.
+ ADD: Reference to/referenced by information is now included in the XML
       output.
+ BUG: The HIDE_UNDOC_CLASSES option did not work correctly for template
       instances when set to YES.
+ BUG: \line, \skipline and \until introduced too many new lines.
+ BUG: Doxygen did not parse "struct {} typedef S;" correctly.
-----------------------------------------------------------------------------
Enjoy,
  Dimitri

[Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

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

Hi to all.
I'm beginning writting the documentation of my C library, using Doxygen.

The fist document is a reference manual.
I can't disable some default's doxigen features.

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

A) I dont want show the source code to developers. but I need include the=
 *.c
files in the INPUT secctions.


B) I want disable all references to de definition of a function.:

	Example:

	char * gs_cda_drive_get_label ( GsCdaDrive *  drv )

	Parameters : Get a String containing The model of this GsCdaDrive Drive
	Unit. Returns :  A GsCdaDrive Object.

	Definition at line 50 of file gscdadrive.c.  <-------NO NO NO!!!!

C) Enums:
  I asign a value to all "labels" in my enums.

	Example:

	enum MyEnum {
		MYVAL_0 =3D 0,
		MYVAL_1 =3D 3,
		MYVAL_2 =3D 0x08,
	}

The doxigen outputs , maintains the values, but I would like only showing

	enum MyEnum {
		MYVAL_0,
		MYVAL_1,
		MYVAL_2,
	}

D) defines and Macros:

Due to internal design I need A lot of macro #defines
Can I document 'it. like a function, this is , hidding the body of the ma=
cro?

example:

	#define DO_SOMETHING(a,b)  \
		({		\
		XXXXXXX	\
		XXXXXX	\
		XXXXXX
		})		\

	I would like to document it like...

	macro DO_SOMETHING(a,b)
	returns : a boolean if a & b .....


--------------------------------------------------------
Can you help me please?

I have attached an html output file, that shows how macros dirty the
reference manual ( there are aprox 30 indocumented macros yet !!!).

Thanks to all.
And sorry by my poor English.

--
=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
(Barcelona) Spain.
CP: 08340

Re: [Doxygen-users] html generation error

[Stephane R. <ste...@sy...>]

Hi,

thansk a lot, it's working with %20.

Stephane
----- Original Message ----- 
From: "Stephen Goudge" <ste...@el...>
To: <dox...@li...>
Sent: Friday, November 16, 2001 2:42 AM
Subject: RE: [Doxygen-users] html generation error


> Could it just be that you aren't supposed to spaces into URL's in
> general (whether it be a mailto:, http: or whatever)?
> 
> Try replacing the space with the normal URL encoding for a space, %20,
> as:
> 
> <a href = "mailto:na...@do...?subject=text1%20text2">Mon Nom</a>
> 
> As you're setting the subject, which could be any old text, you should
> also be wary of the other characters that need to be URL encoded; I'm
> afraid I've not got a table of them on hand to cut'n'paste, but they
> should be listed in any HTML book or reference.
> 
> Stephen Goudge
> 
> > -----Original Message-----
> > From: dox...@li...
> > [mailto:dox...@li...] On Behalf
> > Of Stephane Routelous
> > Sent: 15 November 2001 18:42
> > To: dox...@li...
> > Subject: [Doxygen-users] html generation error
> >
> >
> > Hello,
> > Im using Doxyfile 1.2.11.1
> > I've found a problem :
> > I'm using the author tag with :
> > * \author <a href = "mailto:na...@do...?subject=text1
> > text2">Mon Nom</a>
> >
> > But it doesn't work because of the space in the
> > subject.(text1<space>text2) If I write :
> > * \author <a href =
> > "mailto:na...@do...?subject=text1-text2">> Mon Nom</a> It
> > works.
> >
> > Did you also notice the problem ?
> >
> >
> > Thanks,
> >
> > Stephane
> >
> >
> > _______________________________________________
> > 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

RE: [Doxygen-users] Excluding individual structures

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

You might use the "\deprecated" special command (at least in Angela's case)
to indicate that the struct is not intended to be used in the future.

I use \deprecated all the time to flag code that is not going to be around
in the future but that I have not had the time to remove properly (that is,
remove and then run unit tests to insure that nothing broke).

Another option might be the conditional section commands \if \endif etc.

-- 
Onorio Catenacci


> -----Original Message-----
> From: Stephen Goudge [mailto:ste...@el...]
> Sent: Friday, November 16, 2001 2:53 AM
> To: dox...@li...
> Subject: RE: [Doxygen-users] Excluding individual structures
> 
> 
> I don't know of a way to do it as things stand; perhaps a new command,
> \omit, would be the solution?
> 
> Hmm, if a command like like \omit was added then for this, very
> sensible, use then it'd also be a way to handle my more dubious desire
> to hide a "friend" declaration, as I posted a message about yesterday.
> Actually, a _much_ better way of doing what I want :-)
> 
> Stephen Goudge
> 
> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...] On Behalf Of Angela
> Marshall
> Sent: 15 November 2001 20:57
> To: dox...@li...
> Subject: [Doxygen-users] Excluding individual structures
> 
> 
> I am just wondering if Doxygen has is a way to exclude certain
> structures (ie typedef struct  blah) from appearing in the class
> hierarchy.  I am working with code that includes both c++ and c, and
> many of the old c structures are still used, but we are 
> *trying* to get
> rid of them and do not want our users to use them (and also 
> do not want
> to clutter up the class hierarchy list).
> 
> Using HIDE_UNDOC_MEMBERS is not an option, since we are just switching
> to Doxygen and several of our classes are not yet documented in the
> correct style.
> 
> Any help would be greatly appreciated!
> 
> Angela
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

[Doxygen-users] linking to java-packages-documentation in seperate files

[Thomas R. <re...@di...>]

Hi,

I'm currently writing a java-package for which a very good documentation is 
required, therefore I prefere doxygen over javadoc :-)
Since I don't like to include the package-documentaion in an arbitrary chosen 
source-file of the package, I introduced "<subpackagename>.dox" files with 
just

/**
<big comment with neatly seperated sections and such>
*/
package fully.qualified.package.name;

as contents.
This works as expected, but I can't refere to this documentation by linking 
via @link or @ref from the mainpage, at least not in the ways I tried
(@link subpackage, @link fullyqualifiedpackage, setting an @anchor inside the 
.dox-file,...)

Is there a way to achieve this? Not that my life depends on it, but it would 
be fine to be able to link to the package-description from the mainpage, as 
there are a few remarks for my co-workers, and provide them there with 
`direct-access` to some sections would increase the value of the docs a lot.

I hope this question is not too silly  and thank you in advance for help or 
for just reading this :-)

regards,
Tom

-- 
re...@di...

RE: [Doxygen-users] Excluding individual structures

[Stephen G. <ste...@el...>]

I don't know of a way to do it as things stand; perhaps a new command,
\omit, would be the solution?

Hmm, if a command like like \omit was added then for this, very
sensible, use then it'd also be a way to handle my more dubious desire
to hide a "friend" declaration, as I posted a message about yesterday.
Actually, a _much_ better way of doing what I want :-)

Stephen Goudge

-----Original Message-----
From: dox...@li...
[mailto:dox...@li...] On Behalf Of Angela
Marshall
Sent: 15 November 2001 20:57
To: dox...@li...
Subject: [Doxygen-users] Excluding individual structures


I am just wondering if Doxygen has is a way to exclude certain
structures (ie typedef struct  blah) from appearing in the class
hierarchy.  I am working with code that includes both c++ and c, and
many of the old c structures are still used, but we are *trying* to get
rid of them and do not want our users to use them (and also do not want
to clutter up the class hierarchy list).

Using HIDE_UNDOC_MEMBERS is not an option, since we are just switching
to Doxygen and several of our classes are not yet documented in the
correct style.

Any help would be greatly appreciated!

Angela

RE: [Doxygen-users] html generation error

[Stephen G. <ste...@el...>]

Could it just be that you aren't supposed to spaces into URL's in
general (whether it be a mailto:, http: or whatever)?

Try replacing the space with the normal URL encoding for a space, %20,
as:

<a href = "mailto:na...@do...?subject=text1%20text2">Mon Nom</a>

As you're setting the subject, which could be any old text, you should
also be wary of the other characters that need to be URL encoded; I'm
afraid I've not got a table of them on hand to cut'n'paste, but they
should be listed in any HTML book or reference.

Stephen Goudge

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...] On Behalf
> Of Stephane Routelous
> Sent: 15 November 2001 18:42
> To: dox...@li...
> Subject: [Doxygen-users] html generation error
>
>
> Hello,
> Im using Doxyfile 1.2.11.1
> I've found a problem :
> I'm using the author tag with :
> * \author <a href = "mailto:na...@do...?subject=text1
> text2">Mon Nom</a>
>
> But it doesn't work because of the space in the
> subject.(text1<space>text2) If I write :
> * \author <a href =
> "mailto:na...@do...?subject=text1-text2">> Mon Nom</a> It
> works.
>
> Did you also notice the problem ?
>
>
> Thanks,
>
> Stephane
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Comments... (was RE: [Doxygen-users] Multiple comments -combining )

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

(Sent to the developers list; the copy sent to doxygen users list -- please
reply in developers)

Hi doxygeners,

It seems that comments in doxygen are discussed more often
now.  Looking at doxygen architecture documentation 
(doxygen/html/arch.html), is there some clear separation 
between the comment parsing and the language construct
parsing?

I think that the separation of the two parsers should be done
before any important changes to comment parsing.  

Why I think so?  It would simplify the comment parsing
enhancements, and it would add flexibility of doxygen design.

The language parser would only recognize some blocks
of the language dependent comments as doxygen comments.
It will implement recognition of various flavours of doxygen
comments.  Its result will be the unified form of a doxygen
comment without language dependent syntactic things plus
some context information.  In other words, the language
parser will convert Qt style, JavaDoc style, block comments,
one-line comments, and whatever future style into one form
that will be passed to the comment parser.

If the language and comment parsers were separated, it 
would be much easier, for example, to process also in-body
comments (that some people asked for).

The comment parser then can be programming language 
indepedent.  This would allow implementing parsing for 
other programming languages.  But also, this would simplify
comment-enhancement development.  In the extreme case,
there could be a possibility to create external comment parsers
that would use different comment syntax.

Well crafted mechanism that will solve the requested
"multiple comment combining" could be used also for
in-body comments.

What is your opinion?

  Petr

-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

> -----Original Message-----
> From:	Stephen Goudge [SMTP:ste...@el...]
> Sent:	Thursday, November 15, 2001 9:13 AM
> To:	dox...@li...
> Subject:	RE: [Doxygen-users] Multiple comments -combining
> 
> The simple combining of comments is a feature that I'd certainly use.
> 
> As others (eg, Victor Wagner) do, we generate two lots of documentation
> from the sources for one library - one set from the public headers,
> detailing the API and examples for users, one with all the
> implementation detail for maintainers.
[...]

Re: [Doxygen-users] Multiple comments -combining

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

You're right, it doesn't help if you have two sets of comments in
different places.  I hadn't actually read that far down the email.  If the
HTML is the primary documentation source, you could combine these
different blocks into blocks in one location and then use a script to
filter them.  If you MUST have the comments in two locations, it doesn't
seem like there's a good way to deal w/ this short of modifying doxygen.

Ted

On Thu, 15 Nov 2001 17:45:29 -0000
"Stephen Goudge" <ste...@el...> wrote:

> Preprocessing like that does eliminate any need to change Doxygen to add
> in any form of 'priority' or selecting comments based on conditions,
> _but_ how do you propose that the comments are combined once the
> pre-processing step has decided which ones to pass on to Doxygen and
> which ones to eliminate?
> 
> What you describe will let you choose that comments are passed through,
> but aren't you still left with the original question from Jan, that you
> could have selected a comment sitting in the header and also one sitting
> in the main source code and these will fight rather than just being
> joined together?
> 
> Aside: If the script just "removes the doxygen prefix" but leaves the
> bulk of the comment in place won't it just disappear from the formatted
> documentation but re-appear in the copy of the source code that Doxygen
> generates? Would the result be neater if the script just eliminated the
> comment entirely?
> 
> Stephen Goudge
> 
> > -----Original Message-----
> > From: dox...@li...
> > [mailto:dox...@li...] On Behalf
> > Of Ted Drain
> > Sent: 15 November 2001 16:45
> > To: Stephen Goudge
> > Cc: dox...@li...
> > Subject: Re: [Doxygen-users] Multiple comments -combining
> >
> >
> > It seems to me that this is already available.  Use the
> > doxygen preprocessor option and it becomes very easy to do
> > all these things.  I've written several python scripts that
> > filter comments based on different conditions.  Based on
> > different tags in the comments (which I defined), the script
> > either passes the comment through to doxygen or removes the
> > doxygen prefix so that the comment is skipped.  When
> > developers write the comments, they insert the tags depending
> > on who the audience is for the comments.  You can even have
> > multiple sections in the comments that are passed through or
> > removed depending on the flags.  This isn't very hard so I
> > don't think there's any need to change doxygen at all.
> >
> <snip>
> >
> > Ted
> >
> > On Thu, 15 Nov 2001 08:13:10 -0000
> > "Stephen Goudge" <ste...@el...> wrote:
> >
> > > The simple combining of comments is a feature that I'd
> > certainly use.
> > >
> > > As others (eg, Victor Wagner) do, we generate two lots of
> > > documentation from the sources for one library - one set from the
> > > public headers, detailing the API and examples for users,
> > one with all
> > > the implementation detail for maintainers.
> > >
> > > We decide what files are read for each set of docs by which
> > > directories are scanned by Doxygen (so there are two Doxygen
> > > configuration files). So to selectively add in comments one
> > just has
> > > to decide which directory to put them into: the
> > configuration files I
> > > write basically discourage putting public headers files and private
> > > implementation files into the same directory. You could get
> > the same
> > > effect by writing the configuration files to match the specifics of
> > > your code: anything that lets you list the public files in
> > one config
> > > and then all the files in the other config (continue for
> > however many
> > > sets of docs you want to generate).
> > >
> <snip>
> > >
> > > Stephen Goudge
> > >
> <snip>
> > > >
> > > > -----Original Message-----
> > > > From: jan...@co...
> > > > [mailto:jan...@co...]
> > > > Sent: Wednesday, 2001
> > > > November 14 10:27
> > > > To: dox...@li...
> > > > Subject: [Doxygen-users] Multiple comments -combining
> > > >
> > > >
> > > > Hi All
> > > >
> > > > Is there any possibility to join multiple comments into one
> > > > description? I would like to have possibility to add the
> > comments in
> > > > header and in source code. The rule that only one description is
> > > > allowed is pretty limiting :-(. I agree with the rule of only one
> > > > brief description, but the detailed description should be
> > possible
> > > > to expand. For example I would like to add some comments to the
> > > > source code that is not my and I want to have comments in
> > separated
> > > > file. If the consistency would be an issue there can be option in
> > > > Doxyfile to turn this thing on/off.
> > > >
> > > > Thanks
> > > >
> > > > 	Honza
> > > >
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Excluding individual structures

[Angela M. <ang...@ca...>]

I am just wondering if Doxygen has is a way to exclude certain =
structures (ie typedef struct  blah) from appearing in the class =
hierarchy.  I am working with code that includes both c++ and c, and =
many of the old c structures are still used, but we are *trying* to get =
rid of them and do not want our users to use them (and also do not want =
to clutter up the class hierarchy list).

Using HIDE_UNDOC_MEMBERS is not an option, since we are just switching =
to Doxygen and several of our classes are not yet documented in the =
correct style. =20

Any help would be greatly appreciated!

Angela

Re: [Doxygen-users] html generation error

[Stephane R. <ste...@sy...>]

Hi,

I dont't use space in filenames, what I want to do is :

/**
* \namespace exotkAF_Application_Datas
* \brief namespace for the exotkAF_Application class
* \author <a href =
"mailto:ste...@al...?subject=namespace
exotkAF_Application_Datas">Stephane Routelous</a>
*/
namespace exotkAF_Application_Datas
{
...
}

The space is in the subject of the mail send when you click on my name in
the Author section.

Stephane


----- Original Message -----
From: "Glenn Maxey" <gle...@vo...>
To: "Stephane Routelous" <ste...@sy...>;
<dox...@li...>
Sent: Thursday, November 15, 2001 1:56 PM
Subject: RE: [Doxygen-users] html generation error


As a general rule, I never create directories or filenames with spaces.
It always seems to come back to haunt me. If I don't have spaces, I find
that tools purchased or developed function better.

I also get the impression that Unix only pays lip-service to spaces in
the name, particularly from the command line. I know you can put quotes
around it. I prefer having names that didn't cause problems.

As for Doxygen, I have had other problems with HREFs that contain
relative path information. I discovered that between generating it and
/or running doxytag on it later to resolve TAG components, it would
really muck up my hyperlinks.

The solution for me was to create HREFs with some keyword that I
recognized. Upon completion of Doxygen and doxytag, I'd run another tool
which among other things changed that keyword to the true relative path
that I desired.

> -----Original Message-----
> From: Stephane Routelous [mailto:ste...@sy...]
> Sent: Thursday, November 15, 2001 11:42 AM
> To: dox...@li...
> Subject: [Doxygen-users] html generation error
>
>
> Hello,
> Im using Doxyfile 1.2.11.1
> I've found a problem :
> I'm using the author tag with :
> * \author <a href = "mailto:na...@do...?subject=text1
> text2">Mon Nom</a>
>
> But it doesn't work because of the space in the
> subject.(text1<space>text2)
> If I write :
> * \author <a href =
> "mailto:na...@do...?subject=text1-text2">Mon Nom</a>
> It works.

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

RE: [Doxygen-users] html generation error

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

As a general rule, I never create directories or filenames with spaces.
It always seems to come back to haunt me. If I don't have spaces, I find
that tools purchased or developed function better.=20

I also get the impression that Unix only pays lip-service to spaces in
the name, particularly from the command line. I know you can put quotes
around it. I prefer having names that didn't cause problems.

As for Doxygen, I have had other problems with HREFs that contain
relative path information. I discovered that between generating it and
/or running doxytag on it later to resolve TAG components, it would
really muck up my hyperlinks.

The solution for me was to create HREFs with some keyword that I
recognized. Upon completion of Doxygen and doxytag, I'd run another tool
which among other things changed that keyword to the true relative path
that I desired.

> -----Original Message-----
> From: Stephane Routelous [mailto:ste...@sy...]
> Sent: Thursday, November 15, 2001 11:42 AM
> To: dox...@li...
> Subject: [Doxygen-users] html generation error
>=20
>=20
> Hello,
> Im using Doxyfile 1.2.11.1
> I've found a problem :
> I'm using the author tag with :
> * \author <a href =3D "mailto:na...@do...?subject=3Dtext1=20
> text2">Mon Nom</a>
>=20
> But it doesn't work because of the space in the=20
> subject.(text1<space>text2)
> If I write :
> * \author <a href =3D=20
> "mailto:na...@do...?subject=3Dtext1-text2">Mon Nom</a>
> It works.

[Doxygen-users] html generation error

[Stephane R. <ste...@sy...>]

Hello,
Im using Doxyfile 1.2.11.1
I've found a problem :
I'm using the author tag with :
* \author <a href = "mailto:na...@do...?subject=text1 text2">Mon Nom</a>

But it doesn't work because of the space in the subject.(text1<space>text2)
If I write :
* \author <a href = "mailto:na...@do...?subject=text1-text2">Mon Nom</a>
It works.

Did you also notice the problem ?

Thanks,

Stephane

RE: [Doxygen-users] Multiple comments -combining

[Stephen G. <ste...@el...>]

Preprocessing like that does eliminate any need to change Doxygen to add
in any form of 'priority' or selecting comments based on conditions,
_but_ how do you propose that the comments are combined once the
pre-processing step has decided which ones to pass on to Doxygen and
which ones to eliminate?

What you describe will let you choose that comments are passed through,
but aren't you still left with the original question from Jan, that you
could have selected a comment sitting in the header and also one sitting
in the main source code and these will fight rather than just being
joined together?

Aside: If the script just "removes the doxygen prefix" but leaves the
bulk of the comment in place won't it just disappear from the formatted
documentation but re-appear in the copy of the source code that Doxygen
generates? Would the result be neater if the script just eliminated the
comment entirely?

Stephen Goudge

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...] On Behalf
> Of Ted Drain
> Sent: 15 November 2001 16:45
> To: Stephen Goudge
> Cc: dox...@li...
> Subject: Re: [Doxygen-users] Multiple comments -combining
>
>
> It seems to me that this is already available.  Use the
> doxygen preprocessor option and it becomes very easy to do
> all these things.  I've written several python scripts that
> filter comments based on different conditions.  Based on
> different tags in the comments (which I defined), the script
> either passes the comment through to doxygen or removes the
> doxygen prefix so that the comment is skipped.  When
> developers write the comments, they insert the tags depending
> on who the audience is for the comments.  You can even have
> multiple sections in the comments that are passed through or
> removed depending on the flags.  This isn't very hard so I
> don't think there's any need to change doxygen at all.
>
<snip>
>
> Ted
>
> On Thu, 15 Nov 2001 08:13:10 -0000
> "Stephen Goudge" <ste...@el...> wrote:
>
> > The simple combining of comments is a feature that I'd
> certainly use.
> >
> > As others (eg, Victor Wagner) do, we generate two lots of
> > documentation from the sources for one library - one set from the
> > public headers, detailing the API and examples for users,
> one with all
> > the implementation detail for maintainers.
> >
> > We decide what files are read for each set of docs by which
> > directories are scanned by Doxygen (so there are two Doxygen
> > configuration files). So to selectively add in comments one
> just has
> > to decide which directory to put them into: the
> configuration files I
> > write basically discourage putting public headers files and private
> > implementation files into the same directory. You could get
> the same
> > effect by writing the configuration files to match the specifics of
> > your code: anything that lets you list the public files in
> one config
> > and then all the files in the other config (continue for
> however many
> > sets of docs you want to generate).
> >
<snip>
> >
> > Stephen Goudge
> >
<snip>
> > >
> > > -----Original Message-----
> > > From: jan...@co...
> > > [mailto:jan...@co...]
> > > Sent: Wednesday, 2001
> > > November 14 10:27
> > > To: dox...@li...
> > > Subject: [Doxygen-users] Multiple comments -combining
> > >
> > >
> > > Hi All
> > >
> > > Is there any possibility to join multiple comments into one
> > > description? I would like to have possibility to add the
> comments in
> > > header and in source code. The rule that only one description is
> > > allowed is pretty limiting :-(. I agree with the rule of only one
> > > brief description, but the detailed description should be
> possible
> > > to expand. For example I would like to add some comments to the
> > > source code that is not my and I want to have comments in
> separated
> > > file. If the consistency would be an issue there can be option in
> > > Doxyfile to turn this thing on/off.
> > >
> > > Thanks
> > >
> > > 	Honza
> > >

Re: [Doxygen-users] Multiple comments -combining

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

It seems to me that this is already available.  Use the doxygen
preprocessor option and it becomes very easy to do all these things.  I've
written several python scripts that filter comments based on different
conditions.  Based on different tags in the comments (which I defined),
the script either passes the comment through to doxygen or removes the
doxygen prefix so that the comment is skipped.  When developers write the
comments, they insert the tags depending on who the audience is for the
comments.  You can even have multiple sections in the comments that are
passed through or removed depending on the flags.  This isn't very hard so
I don't think there's any need to change doxygen at all.  

In fact my project was using a different doc tool (perceps) in which we
defined our own commenting style that was expressive enough for our needs,
extremely easy to write, and without long and complicated code words so
that it's easy to read in the source files.  When we discovered doxygen,
which is a much superior tool, we switched.  Rather that convert our
commenting style (which we really liked), I wrote a python script that
converts our comment format into what doxygen expects and set it is the
doxygen preprocessor.  It was very simple to do and allows us to define
our own commenting style.

Ted

On Thu, 15 Nov 2001 08:13:10 -0000
"Stephen Goudge" <ste...@el...> wrote:

> The simple combining of comments is a feature that I'd certainly use.
> 
> As others (eg, Victor Wagner) do, we generate two lots of documentation
> from the sources for one library - one set from the public headers,
> detailing the API and examples for users, one with all the
> implementation detail for maintainers.
> 
> We decide what files are read for each set of docs by which directories
> are scanned by Doxygen (so there are two Doxygen configuration files).
> So to selectively add in comments one just has to decide which directory
> to put them into: the configuration files I write basically discourage
> putting public headers files and private implementation files into the
> same directory. You could get the same effect by writing the
> configuration files to match the specifics of your code: anything that
> lets you list the public files in one config and then all the files in
> the other config (continue for however many sets of docs you want to
> generate).
> 
> I guess I'm saying I don't understand the need for the additional
> complexity of the scheme as described by Victor: perhaps some
> explanation as to why the existing mechanisms for selectively including
> comments (by selecting files) aren't enough if Doxygen just gains a
> simple ability to combine comments.
> 
> Stephen Goudge
> 
> 
> > -----Original Message-----
> > From: dox...@li...
> > [mailto:dox...@li...] On Behalf
> > Of Wagner, Victor
> > Sent: 14 November 2001 16:37
> > To: 'jan...@co...';
> > dox...@li...
> > Subject: RE: [Doxygen-users] Multiple comments -combining
> >
> >
> > If this were to be implemented (and it looks like the start
> > of a pretty good idea), I would like to see the comments from
> > the source code being optionally added.  I reason thusly:
> >
> > The header file is "public".  Everyone who has access to it
> > can read the comments there if desired. The implementation
> > file (.c, .cpp, whatever) is generally information for the
> > developers.  Not everyone has access to this file. At our
> > office we generate two versions of Doxygen output... one for
> > "users" the other for "developers". The ability to add
> > information to the comments _must_, IMO, be selectable.
> >
> > For generality here, I offer three different possibilities,
> > two of which require the comments processor to be given a new
> > optional numeric argument.
> >
> > 1) the config file adds a numeric value which (if the
> > 'number' on the comments is < than the config, the comments
> > will be added).  I choose smaller, so that you can add more
> > and more 'secret' comments to your hearts content.
> >
> > 2) the config file adds a numeric value which if ANDED with
> > the comment argument results in a non-zero value, the
> > comments will be added.  This would allow for a set of up to
> > (32??) "classes" of elements which could be arbitrarily selected.
> >
> > 3) pretty complete generality:  Change the comments processor
> > to accept an arbitrary list of "ID"s to identify the
> > "class"(es) to which this comment belongs.  The config would
> > also add an arbitrary list of "ID"s to identify which
> > "class"(es) of comments to include.
> >
> >
> > -----Original Message-----
> > From: jan...@co...
> > [mailto:jan...@co...]
> > Sent: Wednesday, 2001
> > November 14 10:27
> > To: dox...@li...
> > Subject: [Doxygen-users] Multiple comments -combining
> >
> >
> > Hi All
> >
> > Is there any possibility to join multiple comments into one
> > description? I would like to have possibility to add the
> > comments in header and in source code. The rule that only one
> > description is allowed is pretty limiting :-(. I agree with
> > the rule of only one brief description, but the detailed
> > description should be possible to expand. For example I would
> > like to add some comments to the source code that is not my
> > and I want to have comments in separated file. If the
> > consistency would be an issue there can be option in Doxyfile
> > to turn this thing on/off.
> >
> > Thanks
> >
> > 	Honza
> >
> >
> > _______________________________________________
> > 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
> >
> >
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users