doxygen-users — List for users of doxygen

[Doxygen-users] TODO Lists in CPP implementation files

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

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.

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.

Any ideas?

Allan Metts -- Atlanta


//---------test.h--------------

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;
};


//--------test.cpp--------------

#include <iostream>
#include "test.h"

int TestClass::GetAnotherValue()
{
  return 43;
};

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!

};

[Doxygen-users] Problems with either protected declerations or multiple public/protected tags

[Simrin G. <ri...@cy...>]

I am coming across sections where doxygen cannot seem to find the
decleration for certain class member functions

ie  Warning: member bar of class foo cannot be found

where bar is defined in the header file where the class foo is defined but
it is defined as a proteced member and there are multiple occurances of the
following format

public:
xxxx
xxx
xxxx

protected:
xxxxx
xxxx
xxx
xxx

public:
xxxx
xxxx
xxxx

protected:
xxxx
xxxx
xxxx


Now this is valid C++ format for classes because it is commonly used to
break different function types into sections and is widely recognized.  I am
wondering if Doxygen can't handle the multiple public/proteced sections or
it just cant handle protected sections.  I believe I have everything being
included in my config file (at least as far as I can tell) and don't know
where else I am going wrong.  If this is a known/unknown issue please let me
know.
--
Simrin Singh Grewal
Co-op Engineer
Cypress Semiconductor
(503) 526-1864
ri...@cy...

[Doxygen-users] Bug? - java package namespace resolution

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

   If multiple java classes (in different packages) have the same name, 
only one of them appears in the documentation.

Example:
in file uk/co/greenius/oneModule/commonName.java

   package uk.co.greenius.oneModule;

   /// brief description of this class
   class commonName
   {
   }

and in file uk/co/greenius/anotherModule/commonName.java

   package uk.co.greenius.anotherModule;

   /// different description
   class commonName
   {
   }


in the documentation, the class commonName only appears in the oneModule 
package. (note: the equivilant C++ case of classes in different 
namespaces appears to be handled correctly, with the class also 
appearing multiple times in the alphabetical index)

   I'm using doxygen version 1.1.12, generating HTML output, and also 
using the DOT tool for inheritance and collaboration diagrams.

Edmund.

[Doxygen-users] Problem with latex-code in comments

[Michael M. <moe...@si...>]

Hi!

I'm using doxygen version 1.2.12. Let me show my example:

/*****************
* \page soso
* \class Eine Test Klasse
*
**********************/
class test
{
public:
    testFunc        ///< [A] this is a test-function.
    (
            int i  ///< you will have to give it a value [B] \f$>0\f$.
        );   

    testFunc2       
    (
            int i      ///< you will have to give it a value \f$>0\f$.
        );                ///< [C] this is a second test-function.
};

to [A]: a comment after the function name (ok I see, not after the 
function decl.), but a warning is givven, that theres a '<' comment.... 
but it is much better to read than [C].

to [B]: the html-output just repeats the \f$>0\f$. Latex seems not to 
work in that kind of ///< comments.

Thanks for your attention, Michael
 

[Doxygen-users] Generating RTF files

[Humberto <hum...@es...>]

I don't know if it's an old topic here but I couldn't find out by myself...

When I am trying to generate RTF documentation I can't see the pictures ,
the index and the page numbers probably there is something lacking in the
configuration probably in the command syntax ....
Can anybody tell me ?
Can anybody give me an example of Doxygen generating RTF documentation ?

RE: [Doxygen-users] referencing methods in generated code

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

Hi Jesper,

I can certainly see your point that the name targets within a Doxygen
HTML page would be more useful if they had meaningful names instead of
incremented "a#" names.=20

<a name=3D"a12" doxytag=3D"KDConfigWidget::addGroup">
<a name=3D"KDConfigWidget::addGroup" =
doxytag=3D"KDConfigWidget::addGroup">

I would like to see this, too. It would make hyperlinking from external
systems into the Doxygen generated stuff more predictable.

=3D=3D=3D=3D tale of my workaround =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In my world, I run Doxygen on several code projects. I also export
material from FrameMaker books. I merge all of these mini-HTML systems
into a single comprehensive HTML system.

Ideally, when I write about some code item in FM, I'd like to be able to
hyperlink it directly to where that code item. I couldn't, because I
could not rely on the targets set by Doxygen; the target "a12" may
change the next time Doxygen is run and it discovers added/removed code
items. Another problem for me is that the included deliverables change,
which could make a hyperlink from FM invalid. On top of this, having
multiple Doxygen projects in one system made it more difficult to get
readers to their desired code item.

The solution that I came up with was to provide a comprehensive index.
(They are more likely to turn to this anyway if they run across an item
of interest in the text.)

I had a Perl tool I wrote that post-processes all generated HTML files
in a given directory. I was using it to swap out copyright information
at the bottom and buttons at the top of each HTML file to get that
consistent look-and-feel. I found the doxytag quite useful when I
extended this Perl tool to add support for creating the comprehensive
index.

For all of the HTML files in a directory, this tool creates a temporary
file with a running list of index tokens (text plus URL) taken directly
from these doxytag anchors (or index tokens exported from FM).=20

They are easy to spot with a split statement. (a) I already know the
path and HTML file. (b) The 'name=3D"a12"' is easy to parse out from the
rest of the URL. (c) The text of doxytag is the code item and later
becomes the text for one of the hyperlinks.

Another tool I created in Perl, indexer, parses these temporary files
into a big list. In addition, I have it do what I call "word-chunking"
whereby natural boundaries (white space, punctuation, capitalization
changes) are used to create additional second level index tokens. This
even bigger list then gets alphebetized. I then go through the list,
generate 26 HTML index pages (A-Z), put official HTML syntax around
entries, and handle the first and second level index items.

Hence, for the example above, I'll eventually get these entries:

add
  ...
  <a href=3D"bogus.html#a12>KDConfigWidget::addGroup</a>=20
  ...
...
config
  ...
  <a href=3D"bogus.html#a12>KDConfigWidget::addGroup</a>=20
  ...
...
group
  ...
  <a href=3D"bogus.html#a12>KDConfigWidget::addGroup</a>=20
  ...
...
<a href=3D"bogus.html#a12>KDConfigWidget::addGroup</a>=20
...
widget
  ...
  <a href=3D"bogus.html#a12>KDConfigWidget::addGroup</a>=20
  ...
...

If the exact same entry (but different URL) appears more than once, I
start appending little "document" icons after the text which are
hyperlinked appropriately.

The end result is an index that not only spans mini-HTML systems coming
from Doxygen and FM, but also is useful to programmers. If they don't
remember the class name or whether it is "addGroup" or "groupAdd" or
what project it is in, they can still get to the topic through the index
by knowing just "add" or "group".=20

True, it explodes the index; I have about about 16,000 entries for one
product. However, the static HTML index pages are online and fast; it
isn't like you're thumbing throught the hundreds of pages of a paper
book. The index pages display in the navigation frame (to the left),
load fast, scoll easy, control the content frame (to the right), and
have navigation at the top and bottom to take you to the different
letters of the alphabet, TOC, and FTS. The index entries are more
reliable and not as intrusive as the FTS (which I get from DevaSearch).

As an aside, at one point I figured out how to extend the javascript for
the tree structure to my TOC and Index. (tree.js) This is the one that
has the expanding/collapsing levels. However, it didn't work at all in
Netscape and wasn't very reliable in IE when the number of entries for
my TOC got large. Multiple "static" pages (which are autogenerated one
time) could give the impression of collapsing/expanding at, say, the top
level and were found to be faster.

Just throwing some ideas out there for you.

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: Jesper K. Pedersen [mailto:bl...@kl...]
> Sent: Wednesday, November 28, 2001 3:12 AM
> To: dox...@li...
> Subject: Re: [Doxygen-users] referencing methods in generated code
>=20
>=20
> Chris Niekel <cn...@zo...> writes:
>=20
> | On Mon, Nov 12, 2001 at 09:27:35AM +0100, Jesper K. Pedersen wrote:
> | > I would like to reference methods in the generated HTML,=20
> but looking at the
> | > HTML, I see that the named tags are somthing like "a3",=20
> rather than
> | > something including the method names.=20
> | >=20
> | > Example:
> | > <a name=3D"a1" doxytag=3D"KDConfigWidget::addGroup"></a>
> | >=20
> | > My question thus is, is it possible to reference this=20
> location using
> | > KDConfigWidget::addGroup rather than "a1"?=20
> |=20
> | Doxygen does this quite automatically with the automatic tags.
> | In your documentation, refer to KDConfigWidget::addGroup, or to
> | #addGroup. The link to the class will appear in the output.
> Right, but I want to refer to doxygen generated documentation from
> outside. i.e. from an HTML page, which is not under the control of
> doxygen.=20

[Doxygen-users] problems merging HTML Help

[Aaron B. <Aa...@co...>]

Hi,

I=B4m using doxygen for generating documentation for several projects. =
It
would be nice to integrate the whole documentation in Visual Studio =
custom
help. For this purpose I want to merge the doxygen generated help files
(compiled with HHC) to a big one. That really sounds easy but the =
problem
is, no index is generated after merging the files.
Someone had this problem before and found a solution?

Thanks in advance,
Aaron

----------------------------------------
Aaron Baur
GMG Weihing GmbH
M=F6mpelgarder Weg 10
72072 T=FCbingen
Germany

phone:        +49(0)7071 9 38 74-0
fax:          +49(0)7071 9 38 74-22
mail to:      aa...@co...

www.colorproof.de
----------------------------------------

Re: [Doxygen-users] referencing methods in generated code

[<bl...@kl...>]

Chris Niekel <cn...@zo...> writes:

| On Mon, Nov 12, 2001 at 09:27:35AM +0100, Jesper K. Pedersen wrote:
| > I would like to reference methods in the generated HTML, but looking at the
| > HTML, I see that the named tags are somthing like "a3", rather than
| > something including the method names. 
| > 
| > Example:
| > <a name="a1" doxytag="KDConfigWidget::addGroup"></a>
| > 
| > My question thus is, is it possible to reference this location using
| > KDConfigWidget::addGroup rather than "a1"? 
| 
| Doxygen does this quite automatically with the automatic tags.
| In your documentation, refer to KDConfigWidget::addGroup, or to
| #addGroup. The link to the class will appear in the output.
Right, but I want to refer to doxygen generated documentation from
outside. i.e. from an HTML page, which is not under the control of
doxygen. 

RE: [Doxygen-users] Documenting an 3rd party SDK

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

Hi Yves,

If I were you, I would get that 3rd party developer to comment their
code, e.g. put Doxygen comments into the header files. You could do it
yourself and send them the updated file and ask them to start using
it/distributing it. Hopefully they are open-minded enough to realize
that commented code is an asset; if they want people to use their SDK,
then put comments in it.

If this preferred method fails due to politics or whatnot, you can fake
out Doxygen. You can put all of your Doxygen comment blocks into a
separate file (e.g., txt). In order to get them to map to the correct
code element, you have to put in a command like @fn or @cl (etc.)
followed by the **exact** prototype on one line at the beginning of each
comment block.

The problem with this technique is that the prototype has to match. If
that 3rd party developer changes their header file, the results will be
code items without comments and nicely worded comments falling through
the cracks if the prototype doesn't match anything in the header files.
It can be a maintenance chore.

Back to my original idea, if you did the first pass at documenting the
header file using Doxygen, you could use (1) reason, (2) business case
justification, (3) clout, (4) executive pressure, etc. to get the 3rd
party developer not only to accept your work but also to maintain it
from then on [or give you a crack at maintaining it.] Either way, it
would actually be a pretty good deal for them and make their SDK even
more marketable.

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: Yves Poissant [mailto:ypo...@mi...]
> Sent: Monday, November 26, 2001 8:55 PM
> To: dox...@li...
> Subject: [Doxygen-users] Documenting an 3rd party SDK
>=20
>=20
> Hi everybody.
>=20
> I would like to use Doxygen to document a 3rd party SDK. The=20
> SDK is being
> updated about every 2 weeks by the company. All I have are=20
> the *.lib, the *.h in
> the include directory and some plugin examples (the SDK is=20
> for developing
> plugins for a 3D animation package) as complete Visual C++=20
> projects with source
> and all. The include files contains about no documentation meaning no
> documentations for classes or members or whatever. Obviously,=20
> I don't want to
> add the documentation inside the header files since they will=20
> change regularly.
> I would like to have Doxigen combine documentation for the=20
> classes and members
> and all that from some external independent documentation=20
> files. Anyone have any
> suggestion as to how to accomplish that?
>=20
> I was thinking of writing some fake implementation files that=20
> would parallel
> each header files in which I would add the documentation. I=20
> can see how to
> document member functions using this trick but how could I=20
> document member
> variables?
>=20
> Is there any other easier way to do that?
>=20
> What about using tag files for this?
>=20
> Do I misunderstand the use of tag files?
>=20
> Yves Poissant
>=20
>=20
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

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

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

Hi,

(the topic is rather old, anyway...)

Carlo Wood wrote:
> On Tue, Nov 20, 2001 at 11:08:03AM +0100, Prikryl,Petr wrote:
> > In the context of my previous comments, I disagree with hiding
> > explicitly stated values of enum items as the default behaviour.
> > I even think that nothing should be changed.
> 
> Make the default behaviour configurable and allow to toggle
> the behaviour per enum with some command.  The is no reason
> not to do that, and there clearly exist the need for this
> with some users.

Yes, I basically agree with enhancements.  On the other hand,
there are some reasons for not adding every possible option to the
configuration file.  Firstly, the more options you have, the more
difficult is to set them correctly.  Secondly--what is probably even
more important--, the more options you have, the more difficult
is to keep the program (doxygen) clear and correct (i.e. bug-free).

To summarize: we can discuss about it, but the ideas should be
very clear before they are to be implemented.

Regards,
  Petr

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

RE: [Doxygen-users] BUG: Input FILE_PATTERNS fails with "c*.h" and "c*.cpp"

[Rainer W. <Rai...@in...>]

> -----Original Message-----
> From: Roland Touchain [mailto:rol...@li...]
> [...]
> Putting [a-l]*.h [a-l]*.cpp in FILE_PATTERNS doesn't work. In=20
> my sample,=20
> only a* and d* files are parsed.  (WinMe, dowygen 1.1.9.1).
>=20
> Thinking that my cfg files were bad, I asked doxygen to make=20
> a brand new=20
> config file, and set
> INPUT                  =3D .
> FILE_PATTERNS          =3D [a-l]*.h [a-l]*.cpp
> Same result: only a* and d* files are parsed (again WinMe, dowygen=20
> 1.1.9.1) [...]

Did you try the following?

  FILE_PATTERNS =3D [a-lA-L]*.h [a-lA-L]*.cpp

For a tool like doxygen that also runs on OSes that have case-sensitive
file names I expect all file name specifications to be case sensitive
also. So that might be the reason why only the a* and d* files are
parsed: they are the only ones that start with a lowercase letter.

Just a guess, did not try it.

--
-- -----------------------------------------------------------------
-- Dipl.-Inform. Rainer Wiesenfarth
-- Inpho GmbH                    E-mail: Rai...@In...
-- Smaragdweg 1                  Phone : +49 711 22881-10
-- 70174 Stuttgart               Fax   : +49 711 22881-11
-- Germany                       URL   : http://www.inpho.de

[Doxygen-users] Documenting an 3rd party SDK

[Yves P. <ypo...@mi...>]

Hi everybody.

I would like to use Doxygen to document a 3rd party SDK. The SDK is being
updated about every 2 weeks by the company. All I have are the *.lib, the *.h in
the include directory and some plugin examples (the SDK is for developing
plugins for a 3D animation package) as complete Visual C++ projects with source
and all. The include files contains about no documentation meaning no
documentations for classes or members or whatever. Obviously, I don't want to
add the documentation inside the header files since they will change regularly.
I would like to have Doxigen combine documentation for the classes and members
and all that from some external independent documentation files. Anyone have any
suggestion as to how to accomplish that?

I was thinking of writing some fake implementation files that would parallel
each header files in which I would add the documentation. I can see how to
document member functions using this trick but how could I document member
variables?

Is there any other easier way to do that?

What about using tag files for this?

Do I misunderstand the use of tag files?

Yves Poissant

[Doxygen-users] Not going to make changes to doxygen

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

On Tue, Nov 27, 2001 at 02:33:49AM +0100, Carlo Wood wrote:
> 1) checkout the latest CVS, configure and compile it
>    and create a test environment that I can work with.

After a closer investigation of my problem, I finally found
out that in most cases doxygen is doing the right thing.
It was very unclear WHEN doxygen will lookup variables/functions/classes
etc. and where it would look etc.  Because I ran often into
cases that it did not work I concluded that it was broken in
general :/.

Fortunately, it seems that doxygen mostly is doing an excellent
job in finding the right classes when referenced in the
documentation (without using the namespace they are in).

It doesn't work inside a @addtogroup inside a namespace;
apparently the fact that this happens inside a namespace is ignored.
But now I know that, I can't afford to put time into that.

I still don't understand when doxygen needs a '\ref'
command to do a lookup (in some cases it seems to make a link
to simple words (like the 'A' in the example my previous post)
while in other cases I need to add an explicit '\ref'... weird.

Back to his own project,

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

[Doxygen-users] Going to make changes to doxygen

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

Hiya,

I just decided to spend some of my time on doxygen,
and therefore subscribed to doxygen-develop.

Normally I first ask what is the chance that a patch
will be added, but in this case I need the patch
hard enough to make it worthwhile if only I would
be one who'd use it, so I'll write it anyway ;).

The first thing I plan to write is a better support
for namespaces:

Instead of searching global namespace only, I want
doxygen to search the _current_ namespace first,
and then the global namespace.  Thus:

class FOOBAR;

namespace n {
  class FOOBAR;

  /**
   * A pointer to class FOOBAR.
   */
  FOOBAR* p;
}

Should generate documentation with a link
to n::p and not ::p.

My plans so far are:

0) subscribe to this list and introduce myself.
1) checkout the latest CVS, configure and compile it
   and create a test environment that I can work with.
2) read the documentation on www.doxygen.org for
   developers.

I am afraid I am not very good at introducing myself
so you might want to read the 1116 pages that show up on
http://www.altavista.com/sites/search/web?q=%22Carlo+Wood%22+AND+NOT+Vendors&kl=XX&r=&d2=0&d0=&d1=&nbq=20&pg=aq&search=Search
or perhaps just the links of my introduction at the bottom
of http://www.gnu.org/people/people.html

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

RE: [Doxygen-users] Internal doco still output when INTERNAL_DOCS is set to NO

[Yann, T. <TRE...@ca...>]

It would be more meaningful if the current option INTERNAL_DOCS was renamed
to MARK_INTERNAL_DOCS, and a new option HIDE_INTERNAL_DOCS was introduced.

For backward compatibility the INTERNAL_DOCS option could be deprecated,
generating a warning if used. Eventually it should be removed.

Trevor

-----Original Message-----
From: Glenn Maxey [mailto:gle...@vo...]
Sent: Tuesday, 27 November 2001 3:00 AM
To: Yann, Trevor; dox...@li...
Subject: RE: [Doxygen-users] Internal doco still output when
INTERNAL_DOCS is set to NO


I agree with Trevor regarding how the @internal command works.

IMHO when INTERNAL_DOCS is NO and a code comment block contains
@internal, then that code comment block as well as the associated code
item should be surpressed from the output.

The way it works now is misleading. @internal merely appends the
statement "For Internal Use only." 

I mean, if the developer or I know that something is only for internal
use, we can certainly write that into the code comments. That's a
no-brainer. It's only a few words longer than @internal. This way the
code is up to date.

However, if a code item is for internal use only, what we really need is
a mechanism to surpress the comment block (and code item) from appearing
in the output. This is what we think we are doing when we tag something
as @internal. This is not the case.

Glenn

> -----Original Message-----
> From: Yann, Trevor [mailto:TRE...@ca...]
> Sent: Sunday, November 25, 2001 9:43 PM
> To: dox...@li...
> Subject: [Doxygen-users] Internal doco still output when INTERNAL_DOCS
> is set to NO
> 
> 
> I have a source file that contains definitions that I would 
> like to suppress
> when generating user doco. It appears that I can mark the 
> declarations with
> \internal, and then use INTERNAL_DOCS to control the output.
> 
> I always see documentation entries, regardless of the setting of
> INTERNAL_DOCS. I expected that with INTERNAL_DOCS set to YES, 
> that I would
> see the documentation, along with "For internal use only". With
> INTERNAL_DOCS set to NO, I don't expect the item to be listed at all.
> 
> TIA,
> 
> Trevor
> 
> 
> Example source code
> -------------------
> 
> /** Number of PEM types that represent keys
>  *  @internal
>  */
> #define NUM_KEY_TYPES   8
> 
> Output with INTERNAL_DOCS set to NO
> -----------------------------------
> 
> #define NUM_KEY_TYPES  
>  
>    Number of PEM types that represent keys 
> 
> For internal use only. 
>  
> Output with INTERNAL_DOCS set to YES
> ------------------------------------
> #define NUM_CERT_TYPES  
>  
>    Number of PEM types that represent certificates 
>  
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

Re: [Doxygen-users] BUG: Input FILE_PATTERNS fails with "c*.h" and "c*.cpp"

[Roland T. <rol...@li...>]

 >Is what you are saying that setting FILE_PATTERNS to c*.cpp c*.h will
 >include all files even those not starting with a "c"? I haven't been able
 >to reproduce that, with a simple set of empty files.
 >...

Here is a zip with a few files. Command 'doxygen A_L.cfg'  fails : doxygen 
parses p* and r* files which are NOT in the wildcards of FILE_PATTERNS. 
This fails with:
Win2k SP2 and doxygen 1.2.12
Win Me and doxygen 1.2.9.1
Win 98 SP2 and doxygen 1.2.9.1

	If I delete the line with 'c', it works fine.( only a* to l* files, but no 
c*).

 >...
 >By the way: you can also specify ranges like [a-l]*.cpp
 >...
Putting [a-l]*.h [a-l]*.cpp in FILE_PATTERNS doesn't work. In my sample, 
only a* and d* files are parsed.  (WinMe, dowygen 1.1.9.1).

Thinking that my cfg files were bad, I asked doxygen to make a brand new 
config file, and set
INPUT                  = .
FILE_PATTERNS          = [a-l]*.h [a-l]*.cpp
Same result: only a* and d* files are parsed (again WinMe, dowygen 
1.1.9.1).. Perhaps long names are not well parsed ? Or more probably I am 
missing something big ??

I was aware that one can use wildcards. But I don't know if widcards are 
sytem dependant, or are parsed as regular expressions by doxygen itself. A 
few words about wildcard would be nice in the doc.

But I am now thinking that the way I tried for cutting down processing time 
is not the right one. In fact, index.html files generated for each of the 
config files are written at the same place (will not work). Even I specify 
output directories to doxygen, final result will not be exactly the same as 
single config file (i.e. no-tagfile) doc.

I would like to get a full documentation, as one generated by a single 
config file doxygen process. But tag files (as I understand them) only 
provide links between documentations, each one having a mainpage, an index 
and so on. Is there a way to do this ?


Thank for the great tool !
Regards

RE: [Doxygen-users] Internal doco still output when INTERNAL_DOCS is set to NO

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

I agree with Trevor regarding how the @internal command works.

IMHO when INTERNAL_DOCS is NO and a code comment block contains
@internal, then that code comment block as well as the associated code
item should be surpressed from the output.

The way it works now is misleading. @internal merely appends the
statement "For Internal Use only."=20

I mean, if the developer or I know that something is only for internal
use, we can certainly write that into the code comments. That's a
no-brainer. It's only a few words longer than @internal. This way the
code is up to date.

However, if a code item is for internal use only, what we really need is
a mechanism to surpress the comment block (and code item) from appearing
in the output. This is what we think we are doing when we tag something
as @internal. This is not the case.

Glenn

> -----Original Message-----
> From: Yann, Trevor [mailto:TRE...@ca...]
> Sent: Sunday, November 25, 2001 9:43 PM
> To: dox...@li...
> Subject: [Doxygen-users] Internal doco still output when INTERNAL_DOCS
> is set to NO
>=20
>=20
> I have a source file that contains definitions that I would=20
> like to suppress
> when generating user doco. It appears that I can mark the=20
> declarations with
> \internal, and then use INTERNAL_DOCS to control the output.
>=20
> I always see documentation entries, regardless of the setting of
> INTERNAL_DOCS. I expected that with INTERNAL_DOCS set to YES,=20
> that I would
> see the documentation, along with "For internal use only". With
> INTERNAL_DOCS set to NO, I don't expect the item to be listed at all.
>=20
> TIA,
>=20
> Trevor
>=20
>=20
> Example source code
> -------------------
>=20
> /** Number of PEM types that represent keys
>  *  @internal
>  */
> #define NUM_KEY_TYPES   8
>=20
> Output with INTERNAL_DOCS set to NO
> -----------------------------------
>=20
> #define NUM_KEY_TYPES =20
> =20
>    Number of PEM types that represent keys=20
>=20
> For internal use only.=20
> =20
> Output with INTERNAL_DOCS set to YES
> ------------------------------------
> #define NUM_CERT_TYPES =20
> =20
>    Number of PEM types that represent certificates=20
> =20
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

[Doxygen-users] Internal doco still output when INTERNAL_DOCS is set to NO

[Yann, T. <TRE...@ca...>]

I have a source file that contains definitions that I would like to suppress
when generating user doco. It appears that I can mark the declarations with
\internal, and then use INTERNAL_DOCS to control the output.

I always see documentation entries, regardless of the setting of
INTERNAL_DOCS. I expected that with INTERNAL_DOCS set to YES, that I would
see the documentation, along with "For internal use only". With
INTERNAL_DOCS set to NO, I don't expect the item to be listed at all.

TIA,

Trevor


Example source code
-------------------

/** Number of PEM types that represent keys
 *  @internal
 */
#define NUM_KEY_TYPES   8

Output with INTERNAL_DOCS set to NO
-----------------------------------

#define NUM_KEY_TYPES  
 
   Number of PEM types that represent keys 

For internal use only. 
 
Output with INTERNAL_DOCS set to YES
------------------------------------
#define NUM_CERT_TYPES  
 
   Number of PEM types that represent certificates 
 

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

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

Hi,

Here's what has changed in this week's release:
----------------------------------------------------------------------------
+ BUG: Fixed potential bogus link in the references list.
+ BUG: Auto detection of idl files was broken.
+ BUG: Preprocessor did not parse hexadecimal values correctly.
+ ADD: Included languages updates for French, Portuguese, 
       Korean, Italian, Dutch, Slovene and Brazil.
+ ADD: Included patch by Adam Doppelt to make doxysearch work
       better with windows/IIS.
+ BUG: Fixed XML output problem (too many </highlight> tags).
+ ADD: Added more info to the XML output: include dependencies,
       member groups, re-implement relations, const/volatile specifiers,
       namespace info.
----------------------------------------------------------------------------
Enjoy,
  Dimitri

Re: [Doxygen-users] Grouping classes only

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

On Fri, Nov 23, 2001 at 10:33:10AM +0100, Thomas Vanier wrote:
> I've modified my code this way :
> 
> /** @addtogroup g1 */
> class A { ...

I am not sure, but I think that addtogroup
doesn't work on class A in this case.
You need to add /** \{ */ /** \} */,
for example:

/** @addtogroup g1 */
/** @{ */
class A { };
/** @} */

Or use

/** @class A
 * @brief ...
 *
 * blah blah description of class A
 *
 * @ingroup g1
 */
class A { ...

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

[Doxygen-users] what works with new aliases?

[Richard B. <ric...@sk...>]

Hi,
A few questions I tried to search for on sourceforge - but the mail-archive
search-engine is broken:

I am trying to customize Doxygen's output as I am commenting object oriented
Javascript source. This works very nicely, if I specify the properties
manually.
To do this, I added aliases, for instance:

ALIASES = "inherit=\par Inheritance: This inherits from "

So I can do:

@inherit DynEvent

The out put looks like this:

<b>Inheritance: This inherits from DynEvent</b>

What I am trying to do, is make more powerful aliases, maybe something like
this:

ALIASES = "inherit=\par Inheritance: \nThis inherits from: \a \n"

So I could then do this:

@inherit DynEvent most properties of Dynevent are blah blah...

and the output would look like this:

<b>Inheritance:</b>
This inherits from <i>DynEvent</i>
most properties of Dynevent are blah blah...

Can this be done?

And also, is it possible to overwrite a commands default behavior? If I just
want a class to show under a heading, and not on a separate page for
instance?
I tried
ALIASES = "class=\par Class: \n"

but that didn't work.

Thanks for any ideas.
Richard.
www.richardinfo.com

[Doxygen-users] Grouping classes only

[Thomas V. <Tho...@al...>]

Hi

I'm trying to use the doxygen (1.2.8.1) grouping features.

I'd like to group classes only (not typedefs, not enums, not members
...).

I've modified my code this way :

/** @addtogroup g1 */
class A { ...

/** @addtogroup g1 */
class B : public A { ...

/** @addtogroup g2 */
class C { ...


Doxygen generates an HTML page with g1 and g2 (modules index), but g1
and g2 contain nothing.
Should I use the "@defgroup" and "@ingroup" tags instead ?
Or "@{" and "@}" ?

I've read in the mail archive several problems using grouping, should I
use the latest doxygen release ?

Thanks


Thomas

Re:[Doxygen-users] Beginner question

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

> In the congig file, instead of having the
> PROJECT_NUMBER fixed at 1.0., 2.0 or 3.0, etc., I
> would like the PROJECT_NUMBER be dynamically named as
> according to the date when I run doxygen. So, when I
> run doxygen on 1 Jan 2001, I'll get to see the date of
> the project as "1 Jan 2001" instead of a value like
> 2.0.
> 
> Is this possible? The only workaround i could think of
> for now is to use sed to change the PROJECT NUMBER
> before I run doxygen. [and that means I've to dig out
> the sed manuals. :( ]

From the Doxygen doc.:
[in config. files] "Environment variables can be expanded using the pattern
$(ENV_VARIABLE_NAME)."
My suggestion: use a small script to set an environment variable to be the
current date, then run Doxygen.

BTW, a subject like "Setting PROJECT_NUMBER" or something like that is more
useful than your :-) So we can search an archive and easily spot what we a
looking for.

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] [newbi question] - Stripping Doxygen comments

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

> What I have noticed, looking at various groups using Doxygen is that the
> development code contains doxygen comments, but the distributed source
> code does not. (E.g. Doxygen etc..).
> 
> What script / utility is being used to remove the comments before 
> distribution of the source code ?

Doxygen source code isn't a good example of using Doxygen to comment a
program :-)
Dimitri didn't used Doxygen on and don't generate Doxygen doc. for his own
code. This has been already pointed out on this mailing list.
Of course, we all prefer that he works on removing bugs and adding features
that spending a lot of time on documenting the source :-) Even if it would
have been a good introduction to use Doxygen. But now, there are plenty open
source projects using Doxygen, so it is easy to pick an example.

Now, let's take a project in the Doxygen project page, says TinyXml
(http://www.grinninglizard.com/tinyxml/index.html).
If you look at the *real* source, you can see the Doxygen comments.
If you look at the source formatted by Doxygen, they are not there, but if
you take a look at the line numbers, you can see a lot are missing:

00131 
00144     const std::string& Value()  const           { return value; }
00145 
00155     void SetValue( const std::string& _value )      { value = _value;
}

Actually, Doxygen strips out the documentation comments before listing the
source, because they would be redundant with the actual documentation.

BTW, a way to get the source without Doxygen comment could be to view the
source page in a browser, select all, paste in a text editor, remove header and
footer and the line numbers.

Regard.

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

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

[Doxygen-users] Beginner question

[mpkid <mp...@ya...>]

Hi.

In the congig file, instead of having the
PROJECT_NUMBER fixed at 1.0., 2.0 or 3.0, etc., I
would like the PROJECT_NUMBER be dynamically named as
according to the date when I run doxygen. So, when I
run doxygen on 1 Jan 2001, I'll get to see the date of
the project as "1 Jan 2001" instead of a value like
2.0.

Is this possible? The only workaround i could think of
for now is to use sed to change the PROJECT NUMBER
before I run doxygen. [and that means I've to dig out
the sed manuals. :( ]

Thanks.

-kid-

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