doxygen-users — List for users of doxygen

[Doxygen-users] A couple of issues with output

[Bogdan I. <bo...@ne...>]

Hi,

First of all, thanks a lot to Dimitri for fixing the javadoc {@link}. I saw
it's been included in the latest changelog. Very quick turnaround on that
one. I really appreciate that.

I've seen two other small problems. They are illustrated by the example
below:

/**
 * A test class. <br>
 * Details.
 */
class Test
   {
public:
   /**
    * A character constant. Details.
    */
   static const char cOne;
   };

const char Test::cOne='t';


First, the value of Test::cOne is not included in the generated
documentation. The value is included for int or const char* const
constants. It looks like const chars don't behave the same way for some
reason.

Second, it's the problem with the <br> in the class docs. I use
BRIEF_MEMBER_DESC = YES
REPEAT_BRIEF = YES
JAVADOC_AUTOBRIEF = YES
to get a behavior as close as possible to the output of the javadoc tool.
I'm only interested in HTML docs generation.

With the javadoc tool, the detailed description is made up of all the docs,
including the brief description, all copied verbatim. For that reason, it's
quite common to include a <br> after the brief description, to put it on a
different line from the rest of the docs.

Doxygen inserts some <p> tags to separate the brief description from the
rest of the docs in the detailed description. Not a bad idea, actually, but
this gets combined with the <br> tag, and results in a large space being
inserted between the first line and the rest of the docs.

Could the insertion of <p> tags be made a configurable option, so that one
can use comments written for javadoc without modification?

Again, I can hardly classify these as serious problems, but I guess it
would be nice to have them sorted out.

Cheers,
Bogdan

Re: [Doxygen-users] doxygen on AIX 4.3

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

On Mon, Jun 18, 2001 at 05:12:22PM -0400, dr...@ca... wrote:
> Did anyone successfully compile doxygen 1.2.7+ on AIX 4.3 ?
> What compiler version and machine type was used?
> 
> I've tried doxygen 1.2.6 but it gave an "illegal instruction error" with
> two of my larger directories.
> I've finally decided to use VAC++ 5 but now, no doxygen version will
> compile.
> 
> I get the following result when compiling doxygen on AIX aix 4.3.3  VAC++
> V5:
> 
> gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
> /local/bin/gmake -f Makefile.libdoxygen all
> gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
> xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_lex.o ce_lex.cpp
> xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_parse.o
> ce_parse.cpp
> "ce_parse.cpp", line 940.11: 1540-0274 (S) The name lookup for "parseOctal"
> did not find a declaration.

Maybe (just a wild guess) it would help if you let yacc regenerate the
ce_parse.cpp file. Just do a "make distclean ; make" in the src dir.

Regards,
  Dimitri

Re: [Doxygen-users] problem with class hierarchies with templates

[Hendrik S. <Do...@HS...>]

"Christoph Koegl" <ko...@in...> wrote:

> [...] I am afraid that templates are somewhat on a back burner
> since they are not heavily used by most developers. [...] 

  If this is the impression then we, who use templates, 
  have to change it! Templates _are_ used by many 
  developers! ;^> 

> Christoph

  Schobi

[Doxygen-users] doxygen on AIX 4.3

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

Did anyone successfully compile doxygen 1.2.7+ on AIX 4.3 ?
What compiler version and machine type was used?

I've tried doxygen 1.2.6 but it gave an "illegal instruction error" with
two of my larger directories.
I've finally decided to use VAC++ 5 but now, no doxygen version will
compile.

I get the following result when compiling doxygen on AIX aix 4.3.3  VAC++
V5:

        /local/bin/gmake -C qtools
gmake: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
/local/bin/gmake -f Makefile.qtools    all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qbuffer.o
qbuffer.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qcollection.o
qcollection.cpp
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qcstring.o
qcstring.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdatastream.o
qdatastream.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdatetime.o
qdatetime.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdir.o
qdir.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfile.o
qfile.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfileinfo.o
qfileinfo.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgarray.o
qgarray.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgdict.o
qgdict.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qglist.o
qglist.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qglobal.o
qglobal.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgvector.o
qgvector.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qiodevice.o
qiodevice.cpp
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qregexp.o
qregexp.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qstring.o
qstring.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qtextstream.o
qtextstream.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics
of a program.  Please refer to documentation on -O3 and the STRICT option
for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qtextcodec.o
qtextcodec.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qstringlist.o
qstringlist.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qxml.o
qxml.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qmap.o
qmap.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfile_unix.o
qfile_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdir_unix.o
qdir_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o
../objects/qfileinfo_unix.o qfileinfo_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
rm -f ../lib/libqtools.a
ar cq ../lib/libqtools.a ../objects/qbuffer.o ../objects/qcollection.o
../objects/qcstring.o ../objects/qdatastream.o ../objects/qdatetime.o
../objects/qdir.o ../objects/qfile.o ../objects/qfileinfo.o
../objects/qgarray.o ../objects/qgdict.o ../objects/qglist.o
../objects/qglobal.o ../objects/qgvector.o ../objects/qiodevice.o
../objects/qregexp.o ../objects/qstring.o ../objects/qtextstream.o
../objects/qtextcodec.o ../objects/qstringlist.o ../objects/qxml.o
../objects/qmap.o ../objects/qfile_unix.o ../objects/qdir_unix.o
../objects/qfileinfo_unix.o
ranlib ../lib/libqtools.a
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
gmake: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
        /local/bin/gmake -C src
gmake: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
/local/bin/gmake -f Makefile.libdoxycfg all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/config.o config.cpp
rm -f ../lib/libdoxycfg.a
ar cq ../lib/libdoxycfg.a ../objects/config.o
ranlib ../lib/libdoxycfg.a
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
/local/bin/gmake -f Makefile.libdoxygen all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_lex.o ce_lex.cpp
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_parse.o
ce_parse.cpp
"ce_parse.cpp", line 940.11: 1540-0274 (S) The name lookup for "parseOctal"
did not find a declaration.
"cppvalue.h", line 27.19: 1540-1298 (I) "CPPValue parseOctal()" needs to be
declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 943.11: 1540-0274 (S) The name lookup for
"parseDecimal" did not find a declaration.
"cppvalue.h", line 28.19: 1540-1298 (I) "CPPValue parseDecimal()" needs to
be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 946.11: 1540-0274 (S) The name lookup for
"parseHexadecimal" did not find a declaration.
"cppvalue.h", line 29.19: 1540-1298 (I) "CPPValue parseHexadecimal()" needs
to be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 949.11: 1540-0274 (S) The name lookup for
"parseCharacter" did not find a declaration.
"cppvalue.h", line 30.19: 1540-1298 (I) "CPPValue parseCharacter()" needs
to be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 952.11: 1540-0274 (S) The name lookup for "parseFloat"
did not find a declaration.
"cppvalue.h", line 31.19: 1540-1298 (I) "CPPValue parseFloat()" needs to be
declared in the containing scope to be found by name lookup.
gmake[1]: *** [../objects/ce_parse.o] Error 1
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
gmake: *** [all] Error 2
gmake: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
make: 1254-004 The error code from the last command is 2.


Stop.


//-----------------------------------
// Denis Ricard,  IBM Canada
//   dr...@ca...
//-----------------------------------

Re: [Doxygen-users] problem with class hierarchies with templates

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

On Mon, Jun 18, 2001 at 12:15:12PM +0100, Kris Thielemans wrote:
> Hi,
> 
> although nobody seems to be interested in my problem, I'm plodding on...

I am interested, but as Christoph said, also very busy with other things.
I have tried to improve the way doxygen handles templates just for
dot generated inheritance and collaboration graphs. As a result the
other graphs and hierarchies will not be different from before (and thus
rather broken for templates). I plan to improve this later on 
(some help might speed things up!).

> Last time, I told you that the DOT generated inheritance graphs are ok for
> the example I tried. Now I have a case where they aren't. It happens when a
> default template parameter is used.

I'll look at your example and try to fix doxygen.

Regards,
  Dimitri

RE: [Doxygen-users] problem with class hierarchies with templates

[Kris T. <kri...@ic...>]

> Another problem is, of course, that class diagrams
> (such as popularized
> by OMT, Booch, UML, you name it) are inherently unable to
> meaningfully deal with
> parameterized classes, at least with C++'s implementation of this concept.
>
>

I admit I don't have a clear view on this. However, I sort of think that for
leaf-classes, it is perfectly possible to have a clear inheritance diagram
(after all, if there isn't a clear inheritance tree, it won't compile...).
Indeed, at the end of a hierarchy tree, all 'intermediate' templates have to
be resolved (i.e. the only ones left are the template parameters of the
class itself).

The question really is what to do with 'intermediate' classes.

One option would be to do the same as for a 'leaf' class, i.e. you make the
inheritance tree only upto the current class, and do not show whatever is
below it (so, your intermediate class IS a leaf class). It looks like the
dot-generated hierarchies for leaves are already pretty close to this (my
previous mail was a counter-example, but I'd hope it's not too difficult to
take this into account as well).

Another option is to do show whatever comes lower but only heuristically,
i.e. without looking at template arguments at all. One could look at
doxygen's current attempt in this way. As long as this is stated clearly, I
could live with it.

I guess the latter approach could be improved upon by some kind of
postprocessing of the hierarchies: the hierarchy for any intermediate class
could be found by merging the hierarchies of all leaf classes. This doesn't
sound easy though.

What about the 'class hierarchy' list ? It attempts to start at the 'root'
of the hierarchy. This is difficult/impossible for exactly the same reasons
as before. Again, I could live with it if the doc states it somewhere
explicitly. I could imagine doxygen finding out it has troubles with the
templates, so inserting a warning on top of the class hierarchy page.


Summary: an inheritance diagram for anything upwards in the tree should be
doable. For anything downwards, it's getting muddy. The dot-generated
hierarchy seems pretty close, so maybe a few extra fixes make it usable
enough.

(Still beats me how the 'default',i.e. non-dot class hierarchy diagrams can
be different from the other ones. It seems to say that there are 2 pieces of
code to do the same thing in doxygen).

Kris Thielemans
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

Phone on :   +44 (020)8383 3731
FAX on :     +44 (020)8383 2029

web site address:
http://www.irsl.org/~kris

Re: [Doxygen-users] problem with class hierarchies with templates

[Christoph K. <ko...@in...>]

kri...@ic... said:
> Is anyone interested in this at all except me? 

Emphatically, yes!! I sent Dimitri some related examples quite a long time ago, but
as I understand him template parsing has never been a strong point of Doxygen. Dimitri
has loads of stuff to do and I am afraid that templates are somewhat on a back burner
since they are not heavily used by most developers. The current state of affairs makes
Doxygen (a fine documentation tool [the finest!!!], nevertheless) pretty much unusable
for documenting template-heavy code (like template metaprogramming or expression
template libraries). I was about to propose Doxygen as documentation tool for the
boost (www.boost.org) libraries, but initial tests on several of the boost libraries
showed many of Doxygen's limitations in parsing templates. Perhaps Dimitri can
document somewhere Doxygen's actual template parsing capabilities (like explicit
specialization, partial specialization, default parameters, non-type parameters,
inheritance from template parameters classes or from classes dependent on template
parameters). Another problem is, of course, that class diagrams (such as popularized
by OMT, Booch, UML, you name it) are inherently unable to meaningfully deal with
parameterized classes, at least with C++'s implementation of this concept.

Christoph
-- 
================================================================================
Christoph Koegl, Dept. of Computer Science, University of Kaiserslautern

E-Mail: christoph at familie-koegl dot de
WWW: http://www dot familie-koegl dot de/
--------------------------------------------------------------------------------
There are no stupid questions, but there are a LOT of inquisitive idiots.
--------------------------------------------------------------------------------

RE: [Doxygen-users] problem with class hierarchies with templates

[Kris T. <kri...@ic...>]

Hi,

although nobody seems to be interested in my problem, I'm plodding on...

Last time, I told you that the DOT generated inheritance graphs are ok for
the example I tried. Now I have a case where they aren't. It happens when a
default template parameter is used.

The hierarchy
-------------
//! A
template <typename Base>
class AddParser : public Base
{};

//! bla
template < typename Base, typename Parent = AddParser<Base> >
class Intermediate : public Parent
{};

//! bla
class myBase {};

//! This will be shown as derived from Base
class Leaf :  public  Intermediate< myBase  >
{};

//! This will be shown CORRECTLY as derived from myBase
class Leaf2 :  public  Intermediate< myBase,AddParser<myBase>  >
{};


Inheritance as shown in the DOT enabled  graphs:
-------------------------------------------------

myBase :
 WRONG: is shown as having NO derived classes

AddParser : Base
 PARTIALLY CORRECT:
 - the graph does not show that Base is a template parameter
   (that's a refinement)
 - It does not show Intermediate<> as derived class (but one can argue
   this is ok I guess)

Intermediate : AddParser<Base> : Base
   and 'below' Intermediate, there are Leaf and Leaf2
  CORRECT:
  although Intermediate does show any template arguments, so maybe
  it is confusing to see that Leaf and Leaf2 are derived classes,
   but it is also helpful

Leaf:Intermediate<myBase>: AddParser<Base> : Base
  WRONG:
  it is not correctly inferred that Leaf derives from myBase, i.e.
  the template parameter Base is not determined correctly

Leaf2:Intermediate<myBase>: AddParser<myBase> : myBase
  CORRECT



Note that the inheritance diagram of myBase is a disappointment... I now
noticed that in my previous example (see below) also class V is shown as
having no derived classes...

Is anyone interested in this at all except me?

All the best,

Kris


> further on this problem. I've enabled the dot graphs now. And I
> am surprised
> with the result. First the hierarchy again:
>
> > The simplest
> > example of my problem is the following hierarchy
> > //! V
> > class V {};
> > //! K
> > template <class T> class K : public T {};
> > //! KV
> > class KV : public K<V> {};
> >
>
> what is the result?
>
> DOT ENABLED
> -----------
> - In the Class Hierarchy (hierarchy.html), it is not recognised that the
> hierarchy
> is KV : K<V>: V. (It just mentions KV: K). This is also true for the
> graphical hierarchy.
>
> - in the Inheritance diagram of K, I get confusingly
> 	KV : K : T
>   (I'd prefer KV : K<T> : T and some indication that T is a template
> parameter)
>
> - in the Inheritance diagram of KV, I get CORRECTLY
> 	KV : K<V> : V
>
>
> DOT DISABLED
> -----------
> - The Class Hierarchy (hierarchy.html) is the same.
>
> - in the Inheritance diagram of K, I get now
> 	KV : K
>
> - in the Inheritance diagram of KV, I get now
> 	KV : K<V>
>
>
> It's strange that the inheritances are different when dot is
> dis/enabled. I
> hope that it's easy to fix this, as at least one diagram was correct...
>
>
> Attached is my doxygen input file I used.
>
>
> All the best,
>
>
> Kris Thielemans
>
> PS: I'm on the mailing list again
>
>

[Doxygen-users] configure script

[Volker B. <boe...@we...>]

Hi,

the new configure version checks the output of the install tool for option
'--version' to decide if it is the gnu installer. More specific: The
string 'GNU' is expected in the output.

This works pretty for version 4.0:
  $ /usr/bin/install --version
  install (GNU fileutils) 4.0

But it doesn't work for the next version:
  $ install --version
  install (fileutils) 4.1
  Written by David MacKenzie.
  
  Copyright (C) 2001 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.

The only common string is 'fileutils'.
Configuration only works if use ./configure --install /usr/bin/install

BTW why don't you use autoconf?

Regards,
Volker
-- 
Volker Boerchers
boe...@we...

RE: [Doxygen-users] Doxygen-1.2.8-20010617 in CVS

[Olaf B. <ola...@sk...>]

I have noticed that Doxygen has problems finding methods in typical VC++
generated classes.
=20
VC++ typically generates multiple 'public:' and 'protected:' keywords
withing the same class.
If I generate with Doxygen, most of these methods are missing.
But when I clean up duplicate 'public:' and 'protected:' keywords,
Doxygen finds the methods.
=20
Example typical VC++ class where Doxygen only finds Protected method
'CImageFrame()'=20
'~CImageFrame()' is missing!=20
=20
-------------------------
class CImageFrame : public CMDIChildWnd
{
protected:
 CImageFrame();           // protected constructor used by dynamic
creation
 DECLARE_DYNCREATE(CImageFrame)
=20
// Attributes
public:
=20
// Operations
public:
=20
// Overrides
 // ClassWizard generated virtual function overrides
 //{{AFX_VIRTUAL(CImageFrame)
 public:
 protected:
 virtual BOOL PreCreateWindow(CREATESTRUCT& cs);
 //}}AFX_VIRTUAL
=20
// Implementation
protected:
 virtual ~CImageFrame();
=20
 // Generated message map functions
 //{{AFX_MSG(CImageFrame)
 afx_msg void OnClose();
 //}}AFX_MSG
 DECLARE_MESSAGE_MAP()
};
=20
-----------------

=20

[Doxygen-users] Doxygen-1.2.8-20010617 in CVS

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

Hi,

In this week's release the following has changed:
--------------------------------------------------------------------
+ BUG: Removed bogus warnings when parsing tag files.
+ BUG: Image reference to dot images were broken in the RTF output
       (thanks to Henning Moll for the fix).
+ BUG: Linebreaks are now done with \par instead of \line in the RTF
       output (thanks to Henning Moll).
+ BUG: The detailed description in a @name block can now be more than
       plain text.
+ BUG: Included fix for the tree view script for the mozilla browser
       (thanks to Alec Panovici).
+ CHG: Fiend class declarations are now treated as normal members.
+ BUG: Grouping members with the same signature but with a different scopes
       is now possible.
+ BUG: MAN_LINKS option was broken (fixed by Patrick Ohly).
+ BUG: Including a file with \include in LaTeX caused the leading text
       to appear in a smaller font size.
+ BUG: Related functions could not be grouped.
+ ADD: Added GNU install tool auto detection to the configure script.
+ ADD: "make install" now also installs doxygen_xml if enabled using
       the --with-xmlgen option of the configure script.
+ BUG: Improved the documentation (thanks to Jens Seidel).
+ BUG: JavaDoc style links such as @{link #var} and @{link #var label}
       now work.
+ BUG: "doxygen -g -s" now creates a file named Doxyfile i.s.o "-s"
--------------------------------------------------------------------
Enjoy,
  Dimitri

Re: [Doxygen-users] RTF/Word97 - "blank" collaboration and inheritance diagrams

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

On Fri, Jun 15, 2001 at 08:40:36AM -0500, CHUVALA, KEITH G. (JSC-DL2) (USA) wrote:
> I've got a problem with RTF output running Doxygen 1.2.8.1 on NT 4.0 (SP5),
> displaying/printing with Word 97.
> 
> Earlier this year our team used Doxygen 1.2.5 to produce a number of code
> review packages with excellent results.  At that time I'd asked about some
> problems in RTF output, and Joe Ninety contributed some great fixes and
> additions.
> 
> Now we see a new problem that seems to have started in 1.2.7, and continues
> on into 1.2.8.1.  We use most all the graphs in our review packages, so
> we've got configurations that include the following lines:
> 
> HAVE_DOT               = YES
> DOT_PATH               = 
> CLASS_GRAPH            = YES
> COLLABORATION_GRAPH    = YES
> INCLUDE_GRAPH          = YES
> INCLUDED_BY_GRAPH      = YES
> MAX_DOT_GRAPH_WIDTH    = 1024
> MAX_DOT_GRAPH_HEIGHT   = 1024
> 
> The CLASS_GRAPH and COLLABORATION_GRAPH diagrams display and print as blank
> boxes!  They take up the appropriate amount of space in the document, but
> appear as white on white, or have some other problem that yields the same
> effect.  
> 
> The INCLUDE_* diagrams display and print fine.
> 
> The graphics files ARE being produced correctly; the problem shows up ONLY
> in the RTF document.
> 
> Any suggestions?  We're about to embark on a new round of code reviews, and
> I'd sure like to continue using Doxygen!

This is a bug in doxygen. A fix will appear in the next CVS update.

Regards,
  Dimitri

[Doxygen-users] RTF/Word97 - "blank" collaboration and inheritance diagrams

[CHUVALA, K. G. (JSC-D. (USA) <kei...@js...>]

I've got a problem with RTF output running Doxygen 1.2.8.1 on NT 4.0 (SP5),
displaying/printing with Word 97.

Earlier this year our team used Doxygen 1.2.5 to produce a number of code
review packages with excellent results.  At that time I'd asked about some
problems in RTF output, and Joe Ninety contributed some great fixes and
additions.

Now we see a new problem that seems to have started in 1.2.7, and continues
on into 1.2.8.1.  We use most all the graphs in our review packages, so
we've got configurations that include the following lines:

HAVE_DOT               = YES
DOT_PATH               = 
CLASS_GRAPH            = YES
COLLABORATION_GRAPH    = YES
INCLUDE_GRAPH          = YES
INCLUDED_BY_GRAPH      = YES
MAX_DOT_GRAPH_WIDTH    = 1024
MAX_DOT_GRAPH_HEIGHT   = 1024

The CLASS_GRAPH and COLLABORATION_GRAPH diagrams display and print as blank
boxes!  They take up the appropriate amount of space in the document, but
appear as white on white, or have some other problem that yields the same
effect.  

The INCLUDE_* diagrams display and print fine.

The graphics files ARE being produced correctly; the problem shows up ONLY
in the RTF document.

Any suggestions?  We're about to embark on a new round of code reviews, and
I'd sure like to continue using Doxygen!

kgc

___________________________________
Keith G. Chuvala
Space Operations Computing (SpOC) Team
Johnson Space Center
Houston, Texas, USA

RE: [Doxygen-users] include files in subdirectories

[Kris T. <kri...@ic...>]

Hi,

I have to amend this:
- in the file documentation, the full include name is given correctly
- in the class documentation, the subdirs are dropped

I'm using doxygen 1.2.8.1

Kris

> 
> my include files are organised in subdirectories:
> include/tomo/file1.h
> include/tomo/recon_buildblock/file2.h
> 
> I tell doxygen that they all reside in include/, so it finds them nicely.
> However, in the documentation, it drops the subdir part in the include
> statement. Fore example, the doc would say (after the brief section)
> 
> #include "file1.h"
> 
> or
> 
> #include "file2.h"
> 
> I've read  somewhere I can force doxygen to use a particular path somehow
> (the \file statement?), but I don't really want to change all my include
> files to reflect their location in the doyxgen comments. After all, just
> where doxygen found them should be enough to tell it where they are...
> 
> Am I missing something, or is that for the \todo list?
> 
> Kris Thielemans
> 
> Imaging Research Solutions Ltd
> Cyclotron Building
> Hammersmith Hospital
> Du Cane Road
> London W12 ONN, United Kingdom
> 
> Phone on :   +44 (020)8383 3731
> FAX on :     +44 (020)8383 2029
> 
> web site address:
> http://www.irsl.org/~kris
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

[Doxygen-users] Multilingual documentation

[Tobias Z. <Tob...@cw...>]

Hi,
I'm very new with doxygen and I'm trying to build a multilingual
documentation,
I used the \if command to seperate the languages. It all works fine only the
@brief tag does not behave like I thought it should. I tried the following:

/**
*   \if eng
*   @brief  Function for handling UDP errors.
*   \endif
*
*   \if ger
*   @brief  Funktion zur Behandlung von UDP-Fehlern.
*   \endif
*/

but doxygen always puts both @brief tags into the doc no matter whether I
set ENABLED_SECTIONS to eng or ger.
What am I doing wrong?


Tobias Zimmer

Tob...@cw...

[Doxygen-users] include files in subdirectories

[Kris T. <kri...@ic...>]

Hi,

my include files are organised in subdirectories:
include/tomo/file1.h
include/tomo/recon_buildblock/file2.h

I tell doxygen that they all reside in include/, so it finds them nicely.
However, in the documentation, it drops the subdir part in the include
statement. Fore example, the doc would say (after the brief section)

#include "file1.h"

or

#include "file2.h"

I've read  somewhere I can force doxygen to use a particular path somehow
(the \file statement?), but I don't really want to change all my include
files to reflect their location in the doyxgen comments. After all, just
where doxygen found them should be enough to tell it where they are...

Am I missing something, or is that for the \todo list?

Kris Thielemans

Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

Phone on :   +44 (020)8383 3731
FAX on :     +44 (020)8383 2029

web site address:
http://www.irsl.org/~kris

[Doxygen-users] Doxygen wishlist

[Olaf B. <ola...@sk...>]

Something for the Doxygen wish list:
=20
Right now, I am using \see xxxx for references to other functions and
variables.
But it would be nice if we had an option to add all references to this
function or field automatically.=20
=20
Olaf

[Doxygen-users] AIX 4.3 xlc5 compilation problems

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

Hi,

I get the following result when compiling doxygen on AIX aix 4.3.3  VAC++
V5:

        /local/bin/gmake -C qtools
gmake: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
/local/bin/gmake -f Makefile.qtools    all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qbuffer.o
qbuffer.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qcollection.o
qcollection.cpp
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qcstring.o
qcstring.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdatastream.o
qdatastream.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdatetime.o
qdatetime.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdir.o
qdir.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfile.o
qfile.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfileinfo.o
qfileinfo.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgarray.o
qgarray.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgdict.o
qgdict.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qglist.o
qglist.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qglobal.o
qglobal.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qgvector.o
qgvector.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qiodevice.o
qiodevice.cpp
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qregexp.o
qregexp.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qstring.o
qstring.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qtextstream.o
qtextstream.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics
of a program.  Please refer to documentation on -O3 and the STRICT option
for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qtextcodec.o
qtextcodec.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qstringlist.o
qstringlist.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qxml.o
qxml.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qmap.o
qmap.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qfile_unix.o
qfile_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o ../objects/qdir_unix.o
qdir_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
xlC -c -DQT_NO_CODECS -DQT_LITE_UNICODE -O3 -I. -o
../objects/qfileinfo_unix.o qfileinfo_unix.cpp
    1500-036: (I) Optimization level 3 has the potential to alter the
semantics of a program.  Please refer to documentation on -O3 and the
STRICT option for more information.
rm -f ../lib/libqtools.a
ar cq ../lib/libqtools.a ../objects/qbuffer.o ../objects/qcollection.o
../objects/qcstring.o ../objects/qdatastream.o ../objects/qdatetime.o
../objects/qdir.o ../objects/qfile.o ../objects/qfileinfo.o
../objects/qgarray.o ../objects/qgdict.o ../objects/qglist.o
../objects/qglobal.o ../objects/qgvector.o ../objects/qiodevice.o
../objects/qregexp.o ../objects/qstring.o ../objects/qtextstream.o
../objects/qtextcodec.o ../objects/qstringlist.o ../objects/qxml.o
../objects/qmap.o ../objects/qfile_unix.o ../objects/qdir_unix.o
../objects/qfileinfo_unix.o
ranlib ../lib/libqtools.a
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
gmake: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/qtools'
        /local/bin/gmake -C src
gmake: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
/local/bin/gmake -f Makefile.libdoxycfg all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/config.o config.cpp
rm -f ../lib/libdoxycfg.a
ar cq ../lib/libdoxycfg.a ../objects/config.o
ranlib ../lib/libdoxycfg.a
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
/local/bin/gmake -f Makefile.libdoxygen all
gmake[1]: Entering directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_lex.o ce_lex.cpp
xlC -c -+ -qstrict -D_BSD -O3 -I../qtools -o ../objects/ce_parse.o
ce_parse.cpp
"ce_parse.cpp", line 940.11: 1540-0274 (S) The name lookup for "parseOctal"
did not find a declaration.
"cppvalue.h", line 27.19: 1540-1298 (I) "CPPValue parseOctal()" needs to be
declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 943.11: 1540-0274 (S) The name lookup for
"parseDecimal" did not find a declaration.
"cppvalue.h", line 28.19: 1540-1298 (I) "CPPValue parseDecimal()" needs to
be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 946.11: 1540-0274 (S) The name lookup for
"parseHexadecimal" did not find a declaration.
"cppvalue.h", line 29.19: 1540-1298 (I) "CPPValue parseHexadecimal()" needs
to be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 949.11: 1540-0274 (S) The name lookup for
"parseCharacter" did not find a declaration.
"cppvalue.h", line 30.19: 1540-1298 (I) "CPPValue parseCharacter()" needs
to be declared in the containing scope to be found by name lookup.
"ce_parse.cpp", line 952.11: 1540-0274 (S) The name lookup for "parseFloat"
did not find a declaration.
"cppvalue.h", line 31.19: 1540-1298 (I) "CPPValue parseFloat()" needs to be
declared in the containing scope to be found by name lookup.
gmake[1]: *** [../objects/ce_parse.o] Error 1
gmake[1]: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
gmake: *** [all] Error 2
gmake: Leaving directory `/home/dricard/tmp/doxygen-1.2.8.1/src'
make: 1254-004 The error code from the last command is 2.


Stop.


Anyone already had this problem?


//-----------------------------------
// Denis Ricard,  IBM Canada
//   dr...@ca...
//-----------------------------------

Re: [Doxygen-users] Problems with javadoc-style links

[Bogdan I. <bo...@ne...>]

Hello again,

A similar problem: a link of the form

{@link #mf(std::string)}

generates the same kind of warning:

D:/bog/work/tmp2/Test.h:10: Warning: link to unknown entity `string' in the
documentation of this entity!

In this case however, the resulting HTML will contain only 'string'
instead of 'mf(std::string)', which can get quite confusing.

{@link #mf(string)} works fine.

Cheers,
Bogdan



----- Original Message -----
From: "Bogdan Iordanescu" <bo...@ne...>
To: <dox...@li...>
Sent: Thursday, June 14, 2001 5:14 PM
Subject: [Doxygen-users] Problems with javadoc-style links


> Hi,
>
> I encountered a couple of problems trying to use the javadoc-style {@link
> ...} construct.
>
> An example for one of the problems:
>
> /**
>  * This is a test class. Details.
>  */
> class Test
>    {
> public:
>    /**
>     * A member function. This function uses {@link #m}.
>     */
>    void mf();
>
> private:
>    /**
>     * A data member. Details.
>     *
>     * @see #mf()
>     */
>    int m;
>    };
>
> The link to 'm' generates the following error message from Doxygen:
>
> D:/bog/work/tmp2/Test.h:10: Warning: link to unknown entity `m' in the
> documentation of this entity!
>
> A link to a target that contains parentheses, like {@link #mf()}, works
> fine. Also, just inserting #m in the documentation works fine, but I need
> to use the @link tag for various compatibility reasons.
>
> The other problem is that Doxygen doesn't seem to support the construct
> {@link target label}
> This generates the above error message, pointing to 'label'.
>
> Am I doing something wrong? Are these known problems?
>
> I'm using Doxygen 1.2.8.1 on NT4.
>
> Thanks,
> Bogdan
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Problems with javadoc-style links

[Bogdan I. <bo...@ne...>]

Hi,

I encountered a couple of problems trying to use the javadoc-style {@link
...} construct.

An example for one of the problems:

/**
 * This is a test class. Details.
 */
class Test
   {
public:
   /**
    * A member function. This function uses {@link #m}.
    */
   void mf();

private:
   /**
    * A data member. Details.
    *
    * @see #mf()
    */
   int m;
   };

The link to 'm' generates the following error message from Doxygen:

D:/bog/work/tmp2/Test.h:10: Warning: link to unknown entity `m' in the
documentation of this entity!

A link to a target that contains parentheses, like {@link #mf()}, works
fine. Also, just inserting #m in the documentation works fine, but I need
to use the @link tag for various compatibility reasons.

The other problem is that Doxygen doesn't seem to support the construct
{@link target label}
This generates the above error message, pointing to 'label'.

Am I doing something wrong? Are these known problems?

I'm using Doxygen 1.2.8.1 on NT4.

Thanks,
Bogdan

RE: [Doxygen-users] doxygen hangs with incorrect latex input

[Kris T. <kri...@ic...>]

Thanks Luigi!

>          in the configuration file there's a LATEX_BATCHMODE tag that you
> can set to YES to this effect.
>

I guess I'm arguing then that this should be the default setting, or maybe
that this keyword only applies for generating latex doc, but not for the
formulas. (Somehow, you'd want to warn the user though if there was a
problem with latexing _formulas.tex).

Kris

[Doxygen-users] Extract_all and detailed description

[Luigi B. <lui...@ri...>]

Hi all,
	setting EXTRACT_ALL to YES seems to supersede the REPEAT_BRIEF and 
ALWAYS_DETAILED_SEC tags. Namely, running Doxygen on my sources with

EXTRACT_ALL            = YES
HIDE_UNDOC_MEMBERS     = NO
HIDE_UNDOC_CLASSES     = YES
BRIEF_MEMBER_DESC      = YES
REPEAT_BRIEF           = NO
ALWAYS_DETAILED_SEC    = NO
SOURCE_BROWSER         = NO
INLINE_SOURCES         = NO

puts all class members into the "detailed description" section of the 
corresponding class, whether they have a detailed description or not.
Setting EXTRACT_ALL to NO causes only members with a detailed description 
to be documented in detail.

Is this the desired behavior or a bug?

Thanks again,
		Luigi

Re: [Doxygen-users] doxygen hangs with incorrect latex input

[Luigi B. <lui...@ri...>]

At 11:18 AM 6/14/01 +0100, Kris Thielemans wrote:
>I guess the latex process should be run such that it never prompts the user
>for input. This can be done by inserting the \batchmode command at the start
>of the latex file.

Kris,
         in the configuration file there's a LATEX_BATCHMODE tag that you 
can set to YES to this effect.

Bye,
         Luigi

[Doxygen-users] (no subject)

[Luigi B. <lui...@ri...>]

Hi all,
	I just noticed a strange behavior in version 1.2.8.1 under WinNT (I didn't 
check the Linux version). When I run Doxygen through the file:

---- test.hpp ----

//! test class
class Test {
   protected:
     H<C> h;
};

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

and I turn EXTRACT_ALL on, the data member gets documented in the "detailed 
description" section as:

H<C> Test::h<C> [protected]

i.e., there's a spurious <C> after the method (note that H<C> is a 
specialization: C is an actual class, not a template parameter).

If I add documentation to h, either brief or detailed, the extra <C> 
disappears.

Did anyone observe this before? Any light you can shed on it?

Thanks,
	Luigi

[Doxygen-users] Grouping of reimplemented members

[Johan E. <Joh...@ua...>]

Hi,
   grouping of reimplemented members derived from a pure virtual member
doesn't seem to work, using versions 1.2.6 or 1.2.8.1 (other versions
not tested).

Example:
--------   
   Base class: (header file)
      /* \ingroup someGroupName
       *
       * Some desc....
       */
      virtual void methodName() = 0;

   Derived class: (implementation file)
      /* \ingroup someGroupName
       *
       * Some desc....
       */
      void DerivedClassName::methodName()
      {
        .....
      }
      
This gives in the HTML output:

The module description of someGroupName contains only the pure virtual
method and not the derived method.....

Have I documented the methods OK and if that's the case is it a bug?

I've tried to search the archive but I don't seem to get it to work, (I
am subscribing to this list and that's working) do you have to be logged
on to do the search or look at old mails?

/Johan