doxygen-users — List for users of doxygen

Re: [Doxygen-users] Re: Colored Listings in PDF Documentation ?

[Peter B. <Pet...@be...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dimitri !

You can use the style/class file fancyvrb for example !
There is alos a nice class called "listings" which makes fantastic listin=
gs=20
in different colors, etc. in LaTeX !

Hope this helps, because it would be very nice to have the colors in the=20
printed manuals too.

Best Regards=20
Peter Biechele

A

m Montag,  7. Mai 2001 20:30 schrieben Sie:
> On Mon, May 07, 2001 at 02:26:08PM +0200, Peter Biechele wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Is it possible to get the colored listings also in the PDF/LaTeX
> > Documentation ?? (Like they are in the HTML Documentation)
>
> If I knew how to create colored text in a \verbatim LaTeX
> environment it could be added.
>
> Regards,
>   Dimitri
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users

- --=20
#####################################################
Dr. Peter Biechele, E-Mail: Pet...@be...
beXtec GmbH, Gr=FCnderzentrum im "Tabakschopf Ringwald"
Kaiserstuhlstr. 3, D-79312 Emmendingen, Germany
Tel.: +49 7641 93339 61, Fax: +49 7641 93339 69



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6+WyLkveh9aGZ5GcRAngeAJ9mN3uxrI2afi+cxvxqQXjXupWCHQCeMv8b
061dbR4cr1BHBxCkUTrWRJY=3D
=3DI83b
-----END PGP SIGNATURE-----

[Doxygen-users] ordered list and restriction tag additions

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

Hi,

Is there any way to have ordered list using doxygen tags without html?
If there isn't, could Dimitri add a  "\oli" tag  which would give a correct
ordered list in
all output formats?

Also, would-it be possible to add a \restrictions command? I know I can use
alias
but I'm trying to be as much independent from special tags as possible. I
just think
that a function's restriction is between \note, \warning and \todo.


Thanks.


//-----------------------------------
// Denis Ricard,  IBM Canada
//   dr...@ca...
//   416 - 448 - 4124
//-----------------------------------

[Doxygen-users] "free-style" man pages

[Patrick O. <Pat...@pa...>]

Hi!

I noticed that creation of documentation defined via \page
was disabled for man output, probably because it wasn't
really useful.

I have made some changes that make it possible to use \page,
\section and \subsection to create a reasonable man page, e.g.
for commands:

- added support for sections and subsections in man pages
  and enabled output of \pages as man
- extended the usage of MAN_EXTENSION: now it also defines
  which section is used in the man path and the .TH line
- actually distinguish between \section and \subsection
  when writing \pages

The last thing puzzled me a bit: in doxygen.cpp:generatePageDocs()
all sections were printed, but without telling the output
generator whether they were sections or subsections (last
argument of start/endSection). I have changed that and it works
fine in html (using H2/H3) and man (.SH/.SS). 

Patches attached - I hope they are useful.

BTW, who is using the man output and for what purposes?
I just want to know if these changes might break anything
currently in use already.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

RE: [Doxygen-users] Sort not 'complete' in 1.2.7

[Wagner, V. <VW...@se...>]

Thank you for your prompt attention

-----Original Message-----
From: Dimitri van Heesch [mailto:di...@st...]
Sent: Tuesday, 2001 May 08 13:12
To: dox...@li...
Subject: Re: [Doxygen-users] Sort not 'complete' in 1.2.7


On Tue, May 08, 2001 at 11:07:56AM -0400, Wagner, Victor wrote:
> I just noticed that the "compound members" list is only partially sorted.
> I'm running the Win2K version which I downloaded.
> 
> This problem occurred once in the past and I was told that it was a code
> generation problem in VC++ which had been cured by the installation of
sp4.

Yes, but for 1.2.7 I used a different PC and forgot to
apply the service pack to that copy of VC :-( 
The fix is the same as last time: just download the binary again.

Regards,
  Dimitri

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


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

Re: [Doxygen-users] Sort not 'complete' in 1.2.7

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

On Tue, May 08, 2001 at 11:07:56AM -0400, Wagner, Victor wrote:
> I just noticed that the "compound members" list is only partially sorted.
> I'm running the Win2K version which I downloaded.
> 
> This problem occurred once in the past and I was told that it was a code
> generation problem in VC++ which had been cured by the installation of sp4.

Yes, but for 1.2.7 I used a different PC and forgot to
apply the service pack to that copy of VC :-( 
The fix is the same as last time: just download the binary again.

Regards,
  Dimitri

RE: [Doxygen-users] documenting friend functions

[Wagner, V. <VW...@se...>]

I put my friend << and >> inside my classes also so that Doxygen gets them
in the 'right' place in the docs

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@ri...]
Sent: Tuesday, 2001 May 08 12:35
To: dox...@li...;
dox...@li...
Subject: Re: [Doxygen-users] documenting friend functions


At 08:54 AM 5/8/01 -0600, Rod Ollerhead wrote:
>Trying to get documentation for a friend function that is not contained
>within the class it is a friend of.  Any ideas?  How does doxygen
>understand and document friend classes?

Rod,
         the following works for me with the latest Doxygen and a freshly 
generated configuration file:

/*! \file blah.cpp
     \brief blah
*/

//! blah
class blah {
  /*!
   *  Get a string for debug output.
   *  @param    stream    IN    The stream to add to
   *  @param    obj       IN    The message ID to display
   *  @return   The stream with the message ID added
   */
     friend ostream& operator<<( ostream& stream, const MsgId& obj );
};

Doxygen puts the operator<< documentation into the "Friends and related 
functions" section of class blah. It doesn't even need to see the 
operator<< definition in the other file.

Bye,
         Luigi


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


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

Re: [Doxygen-users] documenting friend functions - use @relate

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

Aww, sorry for jumping the gun.  Further study into the documentation told
me the answer is the @relate parameter.

Rod Ollerhead wrote:

> Trying to get documentation for a friend function that is not contained
> within the class it is a friend of.  Any ideas?  How does doxygen
> understand and document friend classes?
>
> class blah
> {
>
>  /**
>      *  Get a string for debug output.
>      *  @param    stream    IN    The stream to add to
>      *  @param    obj       IN    The message ID to display
>      *  @return   The stream with the message ID added
>      */
> friend ostream& operator<<( ostream& stream, const MsgId& obj );
> }
>
> and in a another .h file the stream operator is defined
>
> inline ostream& operator<<(
>         ostream& stream,
>         const MsgId& obj )
> {
>     ....
> }
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] documenting friend functions

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

At 08:54 AM 5/8/01 -0600, Rod Ollerhead wrote:
>Trying to get documentation for a friend function that is not contained
>within the class it is a friend of.  Any ideas?  How does doxygen
>understand and document friend classes?

Rod,
         the following works for me with the latest Doxygen and a freshly 
generated configuration file:

/*! \file blah.cpp
     \brief blah
*/

//! blah
class blah {
  /*!
   *  Get a string for debug output.
   *  @param    stream    IN    The stream to add to
   *  @param    obj       IN    The message ID to display
   *  @return   The stream with the message ID added
   */
     friend ostream& operator<<( ostream& stream, const MsgId& obj );
};

Doxygen puts the operator<< documentation into the "Friends and related 
functions" section of class blah. It doesn't even need to see the 
operator<< definition in the other file.

Bye,
         Luigi

[Doxygen-users] Sort not 'complete' in 1.2.7

[Wagner, V. <VW...@se...>]

I just noticed that the "compound members" list is only partially sorted.
I'm running the Win2K version which I downloaded.

This problem occurred once in the past and I was told that it was a code
generation problem in VC++ which had been cured by the installation of sp4.


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

[Doxygen-users] documenting friend functions

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

Trying to get documentation for a friend function that is not contained
within the class it is a friend of.  Any ideas?  How does doxygen
understand and document friend classes?

class blah
{

 /**
     *  Get a string for debug output.
     *  @param    stream    IN    The stream to add to
     *  @param    obj       IN    The message ID to display
     *  @return   The stream with the message ID added
     */
friend ostream& operator<<( ostream& stream, const MsgId& obj );
}

and in a another .h file the stream operator is defined

inline ostream& operator<<(
        ostream& stream,
        const MsgId& obj )
{
    ....
}

RE: (off-topic) RE: [Doxygen-users] Documenting IDL

[Wagner, V. <VW...@se...>]

I didn't say operator int(), I said operator void* ().  There is a large
difference.
the problem of 'adding' your own test is that it isn't the same as:
real pointers
STL iterators

-----Original Message-----
From: Stephen Goudge [mailto:ste...@pi...]
Sent: Tuesday, 2001 May 08 09:31
To: dox...@li...
Subject: (off-topic) RE: [Doxygen-users] Documenting IDL

[deleted]

Ah, the number of problems trying to do that caused me :-(

I did originally have an operator int() that could be used in if-statements,
which worked fine using VC++2 through to VC++4; then a client bought VC++5
and
it became ambiguous (I forget the precise reason why), so everything
switched to
IsValid() from then on.

I would be tempted nowadays to try and hid IsValid(), but I take the
attitude
that if something was done because one compiler needed it (and the results
are
still legal) then keep it in, because the code will be used on a.n.other
compiler next week, or the week after...

Even with a decent compiler, there is the vexed question of what the cast
operator should be casting _to_ - you don't really want to return another
pointer type, as that looks too much like you're providing a backdoor. These
days, 'bool' would be a reasonable choice (now that the compilers actually
support 'bool'). The best choice would be the mythical 'logical' type that
'if',
'while' etc use, but that isn't available :-(

Stephen Goudge


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


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

(off-topic) RE: [Doxygen-users] Documenting IDL

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

> From: dox...@li...
> [mailto:dox...@li...]On Behalf
> Of Victor A.
> Wagner, Jr.
> Sent: 08 May 2001 12:17
> To: dox...@li...
> Subject: RE: [Doxygen-users] Documenting IDL
>
>
> Slightly off topic (maybe this is C++ style):
> Is there some reason you chose to write IsValid() rather than
> overloading a
> conversion to void*:
>
> operator void*() {return static_cast<void*>(IsValid());}
> would suffice.
>
> Then you could write (like the 'real pointer' you're emulating:
> ThingPtr fred;
> .
> .
> .
> if (fred)
>     fred->DoSomething();
>
> similarly for operator !()
> so you can write:
> if (!fred)
>     blah....blah...
> At Tuesday 2001/05/08 04:02, you wrote:
> > > -----Original Message-----
> > > From: dox...@li...
> > > [mailto:dox...@li...]On
> Behalf Of Dale
> > > Ogilvie
> > > Sent: 08 May 2001 06:27
> > > To: 'dox...@li...'
> > > Subject: [Doxygen-users] Documenting IDL
> >[deleted]
> >There is a problem though - many "smart-pointer" classes
> also declare
> >their own
> >methods: quick example, I have a ref counting pointer that declares
> >IsValid() to
> >check for
> whatever-the-condition-is-that-corresponds-to-a-non-null-pointer:
> >
> >  ThingPtr fred;
> >  ..blah..
> >  if (fred.IsValid())
> >     fred->DoSomething();
> >
> >[I have less trivial methods on some pseudo-pointer classes as well]
> >
> >So if you convert from ThingPtr to Thing every time there is
> the risk of the
> >documentation's reader missing out on the other methods of ThingPtr.
> >

Ah, the number of problems trying to do that caused me :-(

I did originally have an operator int() that could be used in if-statements,
which worked fine using VC++2 through to VC++4; then a client bought VC++5 and
it became ambiguous (I forget the precise reason why), so everything switched to
IsValid() from then on.

I would be tempted nowadays to try and hid IsValid(), but I take the attitude
that if something was done because one compiler needed it (and the results are
still legal) then keep it in, because the code will be used on a.n.other
compiler next week, or the week after...

Even with a decent compiler, there is the vexed question of what the cast
operator should be casting _to_ - you don't really want to return another
pointer type, as that looks too much like you're providing a backdoor. These
days, 'bool' would be a reasonable choice (now that the compilers actually
support 'bool'). The best choice would be the mythical 'logical' type that 'if',
'while' etc use, but that isn't available :-(

Stephen Goudge

RE: [Doxygen-users] Documenting IDL

[Victor A. W. Jr. <va...@ru...>]

Slightly off topic (maybe this is C++ style):
Is there some reason you chose to write IsValid() rather than overloading a 
conversion to void*:

operator void*() {return static_cast<void*>(IsValid());}
would suffice.

Then you could write (like the 'real pointer' you're emulating:
ThingPtr fred;
.
.
.
if (fred)
    fred->DoSomething();

similarly for operator !()
so you can write:
if (!fred)
    blah....blah...
At Tuesday 2001/05/08 04:02, you wrote:
> > -----Original Message-----
> > From: dox...@li...
> > [mailto:dox...@li...]On Behalf Of Dale
> > Ogilvie
> > Sent: 08 May 2001 06:27
> > To: 'dox...@li...'
> > Subject: [Doxygen-users] Documenting IDL
>[deleted]
>There is a problem though - many "smart-pointer" classes also declare 
>their own
>methods: quick example, I have a ref counting pointer that declares 
>IsValid() to
>check for whatever-the-condition-is-that-corresponds-to-a-non-null-pointer:
>
>  ThingPtr fred;
>  ..blah..
>  if (fred.IsValid())
>     fred->DoSomething();
>
>[I have less trivial methods on some pseudo-pointer classes as well]
>
>So if you convert from ThingPtr to Thing every time there is the risk of the
>documentation's reader missing out on the other methods of ThingPtr.
>
>Regards,
>Stephen Goudge
>
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>http://lists.sourceforge.net/lists/listinfo/doxygen-users

Victor A. Wagner, Jr.
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"

RE: [Doxygen-users] Documenting IDL

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

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf Of Dale
> Ogilvie
> Sent: 08 May 2001 06:27
> To: 'dox...@li...'
> Subject: [Doxygen-users] Documenting IDL
>
>
> Hi,
>
> Does anyone know how to get an identifier to be an alias for another
> identifier in doxygen? Basically, I want two identifiers "IRecord" and
> "IRecordPtr" both to index the same documented COM interface.
>
<snip>
>
> All good, but we also use microsoft smart pointer wrappers for our
> interfaces. These wrapper classes can be treated exactly like
> the interfaces
> they wrap, and they have a number of advantages which mean
> that we tend to
> use them almost exclusively. Instead of writing raw code like:
>
> IRecord* pRecord = NULL;
> ...
> pRecord->Doit();
>
> We tend to use the smart pointer wrappers and write:
>
> IRecordPtr pRecord;
> ...
> pRecord->Doit();
>
> Now to our problem. If we press F1 on IRecordPtr we want the
> help to jump to
> the IRecord topic!
>
> Does anyone know how to get doxygen to treat IRecordPtr as an
> alias for
> IRecord???
>
> thanks
>
> Dale
>

That is a very good question - if I can broaden it out, doesn't it apply to any
class that defines operator->() ? This covers a whole raft of coding idioms that
includes a variety of "smart pointers", which I use a lot in my code.

Perhaps if Doxygen could recognise that operator, note what type it is returning
and generate a reference to the returned type...not really sure how it would
work...


There is a problem though - many "smart-pointer" classes also declare their own
methods: quick example, I have a ref counting pointer that declares IsValid() to
check for whatever-the-condition-is-that-corresponds-to-a-non-null-pointer:

 ThingPtr fred;
 ..blah..
 if (fred.IsValid())
    fred->DoSomething();

[I have less trivial methods on some pseudo-pointer classes as well]

So if you convert from ThingPtr to Thing every time there is the risk of the
documentation's reader missing out on the other methods of ThingPtr.

Regards,
Stephen Goudge

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Patrick O. <Pat...@pa...>]

On Mon, May 07, 2001 at 08:28:30PM +0200, Dimitri van Heesch wrote:
> A member (object of class MemberDef) should have exactly 
> one "container" (a class derived from Definition, excluding 
> MemberDef) to which autolinks will point. 
> 
> Normally (e.g. without user defined groups) the container is
> the "natural" container to which the member belongs
> (for a global function declared in a header file and defined in a 
> source file "natural" it is already a bit ambiguous but anyway...).
> If a member is put in a group and the natural container is
> hidden, then the group will become the autolink container.

This is something I haven't thought of yet, but I'll tryto get
it working.

> > The automatic grouping is applied to test::a, which is probably regarded
> > as a bug and not a feature by most, isn't it?
> 
> Yes, this is a bug indeed. I was trying to make it possible to
> group a variable of an anonymous struct like:
> 
> struct
> {
>   int x;
>   int y;
> } point;
> 
> The bug was introduced as a side-effect of this. 
> You can fix this by uncommenting the context rebuild code in 
> parseCompounds in scanner.l.

I had found that one already - I guess that means there is some
hope that I'll get it right ;-)

> Here is the relevant fragment:
> 
>       gstat = FALSE;
>       virt = Normal;
> 
>       memberGroupId = NOGROUP;
> 
>       // rebuild compound's group context 
>       //QCString *s = ce->groups->first();
>       //if (s)
>       //{
>       // lastDefGroup=*s;
>       //        startGroup();
>       //}
> 
>       //current->mGrpId = memberGroupId = ce->mGrpId;

Are you sure about not setting mGrpId? I hadn't removed that
one, but I haven't tested any member groups either.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] Documenting IDL

[Dale O. <Dal...@tr...>]

Hi,

Does anyone know how to get an identifier to be an alias for another
identifier in doxygen? Basically, I want two identifiers "IRecord" and
"IRecordPtr" both to index the same documented COM interface.

We are using doxygen to document our Microsoft IDL. This produces wonderful
documentation for our COM interfaces, and we have integrated the resulting
compiled HTML into our MS Visual studio help so that when we press F1 on one
of our interface definitions we see the docs for our interface!

All good, but we also use microsoft smart pointer wrappers for our
interfaces. These wrapper classes can be treated exactly like the interfaces
they wrap, and they have a number of advantages which mean that we tend to
use them almost exclusively. Instead of writing raw code like:

IRecord* pRecord = NULL;
...
pRecord->Doit();

We tend to use the smart pointer wrappers and write:

IRecordPtr pRecord;
...
pRecord->Doit();

Now to our problem. If we press F1 on IRecordPtr we want the help to jump to
the IRecord topic!

Does anyone know how to get doxygen to treat IRecordPtr as an alias for
IRecord???

thanks

Dale

[Doxygen-users] doxymacs 0.1.0 released

[Ryan T. S. <ry...@ho...>]

Version 0.1.0 of doxymacs, the elisp package that makes using/creating
Doxygen documentation easier for the {X}Emacs user, is released.

This is the "it works for us, let's see if it works for you" version.

It features:
- looks up documentation for any given symbol in the browser of your
  choice.  Note that this features requires the XML tags file that
  doxygen creates, so you'll need to turn that on in your configuration
  file.
- creates documentation for files, functions etc. automagically in either
  the preset JavaDoc or Qt styles, or, create your own style using
  flexible templates.

Please direct all bug reports, feature requests, patches, and cries for
help to the appropriate forum at Doxymacs' SourceForge page:

http://sourceforge.net/projects/doxymacs/


Thank you.

-- 
Ryan T. Sammartino
http://members.home.net/ryants/
algorithm, n.:
	Trendy dance for hip programmers.

[Doxygen-users] Re: Colored Listings in PDF Documentation ?

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

On Mon, May 07, 2001 at 02:26:08PM +0200, Peter Biechele wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Is it possible to get the colored listings also in the PDF/LaTeX 
> Documentation ?? (Like they are in the HTML Documentation)

If I knew how to create colored text in a \verbatim LaTeX 
environment it could be added.

Regards,
  Dimitri

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

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

On Mon, May 07, 2001 at 09:58:23AM +0200, Patrick Ohly wrote:
> On Fri, May 04, 2001 at 10:21:28PM +0200, Dimitri van Heesch wrote:
> > On Fri, May 04, 2001 at 03:12:54PM +0200, Patrick Ohly wrote:
> > > Hi all!
> > > 
> > > According to the documentation (and implementation) of
> > > \ingroup an entity may be put into several different
> > > groups at once.
> > 
> > Yes, but...
> > 
> > > 
> > > However, later on in groupdef.cpp:addMemberToGroups()
> > > this is detected and triggers a warning (groupdef.cpp, line 617):
> > > 
> > >   Member ... found in multiple groups.!
> > >   The member will be put in group ..., and not group ...
> > > 
> > > The class MemberDef also allows to set only one GroupDef: 
> > >     setGroupDef(GroupDef *gd)        { group=gd; }
> > 
> > ... members are an exception. Anything else can be in multiple groups.
> 
> So the comment "Add a member to all groups it is contained in" for
> groupdef.cpp:addMemberToGroups() is not accurate, is it? Only one
> group is possible.

Yes, that's correct. I've given this some thought and here is 
how I see it now:

A member (object of class MemberDef) should have exactly 
one "container" (a class derived from Definition, excluding 
MemberDef) to which autolinks will point. 

Normally (e.g. without user defined groups) the container is
the "natural" container to which the member belongs
(for a global function declared in a header file and defined in a 
source file "natural" it is already a bit ambiguous but anyway...).
If a member is put in a group and the natural container is
hidden, then the group will become the autolink container.

This way it is possible for a member to be in multiple groups,
and this will make autolinking easier as well, since a member
has all the information to generate the link.

> 
> Anyway, now I understand the problem.
> 
> > > - A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
> > >   in another place (e.g. header files uses \defgroup, C files use
> > >   \addtogroup) - this is currently impossible to implement, but
> > >   something that I have been missing for quite a while.
> > 
> > Well if it is impossible to implement, then feel free to try
> > the impossible :-)
> 
> I will ;-) Of course it's not impossible, but requires more
> information than currently available for an Entry: for each
> entry in Entry::groups addMemberToGroups() needs to know where
> the definition came from to resolve the conflict.
> 
> I guess I will change Entry::groups to a list of pairs of
> group name and a definition where the group name came from
> (\ingroup, @{ @}, member group). Okay?

Yes, that would do I guess.

> 
> BTW, does it make sense to put members of structures into groups?
> 
> /**
>  *  Test class
>  *  \ingroup Group1 Group2
>  */
> struct test {
>     /**
>      * \ingroup Group1
>      * test a
>      */
>     int a;
> };
> 
> This works, but then Group1 is said to contain a variable a, which is
> described as test::a. Okay, I guess if someone really wants to do that
> with \ingroup then he should be able to do so. However, the same
> thing happens with
> 
> /** \defgroup Group1 First Group
>  */
> /*@{*/
> 
> /** Test class
>  *  \ingroup Group1 Group2
>  */
> struct test {
>     /**
>      * test a
>      */
>     int a;
> };
> 
> /*@}*/
> 
> The automatic grouping is applied to test::a, which is probably regarded
> as a bug and not a feature by most, isn't it?

Yes, this is a bug indeed. I was trying to make it possible to
group a variable of an anonymous struct like:

struct
{
  int x;
  int y;
} point;

The bug was introduced as a side-effect of this. 
You can fix this by uncommenting the context rebuild code in 
parseCompounds in scanner.l. Here is the relevant fragment:

      gstat = FALSE;
      virt = Normal;

      memberGroupId = NOGROUP;

      // rebuild compound's group context 
      //QCString *s = ce->groups->first();
      //if (s)
      //{
      // lastDefGroup=*s;
      //        startGroup();
      //}

      //current->mGrpId = memberGroupId = ce->mGrpId;

      scanYYlex() ;
      delete current; current=0;
      ce->program.resize(0);

Anyway, this shows that things have become rather 
complex (well at least to complex for me to understand :-).
So doxygen need restructuring. I have to spend some more 
time on this. 

I've already started to change the way information is stored 
in doxygen. Currently all classes and namespaces are stored as 
flat lists. By keeping the original structure many things should 
become simpler, but this does not yet directly help with the
above problems.

> One more thing: may I change \addtogroup so that it doesn't require
> a \defgroup, but might create the group itself? The reason is that in
> our documentation there is no unique place where we could use \defgroup,
> so I'd rather like to use \addtogroup everywhere and let doxygen sort
> it all out. The current semantic of \addtogroup wouldn't be changed,
> only extended by allowing an optional group title.

I don't have problems with that, as long as it also works like it does now.

Regards,
  Dimitri

[Doxygen-users] Re: References to line numbers

[Bryan B. <b.e...@la...>]

Try turning SOURCE_BROWSER off.  This turned off the cross referencing
to source files for me.  I'm on NT with Doxygen 1.2.7.

Bryan

"Catenacci, Onorio" wrote:
> 
> Hi all,
> 
> I keep receiving mail from both the old doxygen mailing list and the new
> one.  So I'm motivated to ask:
> 
> 1.) Are we supposed to be using the old mailing list, the new one or does it
> matter?
> 
> 2.) Is the old mailing list scheduled to be shut down at some point in the
> future?
> 
> --
> Onorio Catenacci
> 
> "Assiduous and frequent questioning is indeed the first key to wisdom...for
> by doubting we come to inquiry; through inquiring we perceive the truth ..."
> 
> --Peter Abelard, "Sic et Non"
> 
> -----------------------------------------------------------
> Visit http://www.xeqt.com/doxygen/ for elist-administration

-- 
======================================================================
Bryan Barmore, Ph.D.                                      AATT Support
Computer Sciences Corporation                b.e...@la...
Hampton, VA 23693                                     bba...@cs...
757/766-8258                                         FAX: 757/776-2571

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Ronald v. E. <eij...@iq...>]

SGkgQWxsLA0KDQpJZiBwZW9wbGUgc3RhcnQgd29ya2luZyBvbiBncm91cHMgaG93IGFib3V0IGFs
bG93aW5nIHRoZSAvaW5ncm91cCB0byBiZSB1c2VkIHRvIGdyb3VwIG1ldGhvZHMgdG9nZXRoZXIg
Zm9yIGEgY2xhc3MuIFRoaXMgaXMgbm93IHBvc3NpYmxlIHVzaW5nIEB7IEB9IGJ1dCB0aGlzIHJl
cXVpcmVzIHRoYXQgZ3JvdXAgbWVtYmVycyBhcmUgZ3JvdXBlZCBpbiB0aGUgaGVhZGVyIGZpbGVz
IGFzd2VsbC4gSW4gb3VyIHByb2plY3Qgd2Ugd2FudCB0byBrZWVwIGFsbCB0aGUgZG94eWdlbiBp
bmZvcm1hdGlvbiBpbiB0aGUgY3BwIGZpbGVzLiANCg0KQyd5YSwNCg0KICAgIFJvbmFsZA0K

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Patrick O. <Pat...@pa...>]

On Fri, May 04, 2001 at 10:21:28PM +0200, Dimitri van Heesch wrote:
> On Fri, May 04, 2001 at 03:12:54PM +0200, Patrick Ohly wrote:
> > Hi all!
> > 
> > According to the documentation (and implementation) of
> > \ingroup an entity may be put into several different
> > groups at once.
> 
> Yes, but...
> 
> > 
> > However, later on in groupdef.cpp:addMemberToGroups()
> > this is detected and triggers a warning (groupdef.cpp, line 617):
> > 
> >   Member ... found in multiple groups.!
> >   The member will be put in group ..., and not group ...
> > 
> > The class MemberDef also allows to set only one GroupDef: 
> >     setGroupDef(GroupDef *gd)        { group=gd; }
> 
> ... members are an exception. Anything else can be in multiple groups.

So the comment "Add a member to all groups it is contained in" for
groupdef.cpp:addMemberToGroups() is not accurate, is it? Only one
group is possible.

Anyway, now I understand the problem.

> > - A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
> >   in another place (e.g. header files uses \defgroup, C files use
> >   \addtogroup) - this is currently impossible to implement, but
> >   something that I have been missing for quite a while.
> 
> Well if it is impossible to implement, then feel free to try
> the impossible :-)

I will ;-) Of course it's not impossible, but requires more
information than currently available for an Entry: for each
entry in Entry::groups addMemberToGroups() needs to know where
the definition came from to resolve the conflict.

I guess I will change Entry::groups to a list of pairs of
group name and a definition where the group name came from
(\ingroup, @{ @}, member group). Okay?

BTW, does it make sense to put members of structures into groups?

/**
 *  Test class
 *  \ingroup Group1 Group2
 */
struct test {
    /**
     * \ingroup Group1
     * test a
     */
    int a;
};

This works, but then Group1 is said to contain a variable a, which is
described as test::a. Okay, I guess if someone really wants to do that
with \ingroup then he should be able to do so. However, the same
thing happens with

/** \defgroup Group1 First Group
 */
/*@{*/

/** Test class
 *  \ingroup Group1 Group2
 */
struct test {
    /**
     * test a
     */
    int a;
};

/*@}*/

The automatic grouping is applied to test::a, which is probably regarded
as a bug and not a feature by most, isn't it?

One more thing: may I change \addtogroup so that it doesn't require
a \defgroup, but might create the group itself? The reason is that in
our documentation there is no unique place where we could use \defgroup,
so I'd rather like to use \addtogroup everywhere and let doxygen sort
it all out. The current semantic of \addtogroup wouldn't be changed,
only extended by allowing an optional group title.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

Re: [Doxygen-users] Again about translations...

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

On Fri, May 04, 2001 at 11:18:23AM +0200, Prikryl,Petr wrote:
> So, the main problem is to find, where the old method
> was called and think deeply whether newly proposed
> method will not create some apparent obstacles in future.
> 
> Once this is decided, Dimitri (or someone closely 
> cooperating with him) can change the interface of 
> the decided method and create its appropriate 
> default implementation in the adapter class which
> takes advantage of the older method, which
> already gives translated string or substring.
> 
> The maintainters could always look inside a documentation
> whether their implementation is up-to-date or should
> be updated.  (This was not released yet, but the 
> perl script for generating the documentation will probably
> be released soon.)
> 
> There already are examples of the changed interface
> in the last CVS releases.  You may have a look at
> trFiles() which was totally replaced by trFile(params).
> There also are good candidates to use exactly the same
> approach, like trAuthors() and trAuthor() -- not done yet.
> 
> Conclusion: Let's start discussing the changes and 
> select the first candidates.

Yes I agree.

Some obvious candidates can be found by doing a 

grep PROJECT_NAME index.cpp

This will reveal a number of places where the project name is
prefixed with some translatable text.

Regards,
  Dimitri

[Doxygen-users] table support in rtf output

[Jonathan B. <bop...@ne...>]

Hello all.

Word fails to convert and open the RTF output when I have documentation
comments like the example.  I had to create tables this way because I noticed
Doxygen does not directly support tables.  (no \table, \row, \column
commands).  

Anyone have any suggestions?

Thanks
Jonathan

Example:

 \subsection AR Command Packet 0x01 - "Define Region"
 Send a region definition to the pet monitor. Region "0" defines the 
 perimeter of the yard. Up to ten forbidden regions, numbered "1" to "10",
 may also be defined. <em>Note that existing regions may be redefined.</em>

 <center><table>
   <tr><td><b>Byte Location in packet</b></td> <td><b>Value<b></td></tr>
   <tr><td>0</td> <td>0x0F</td></tr>
   <tr><td>1</td> <td>0xF0</td></tr>
   <tr><td>2</td> <td>0x0F</td></tr>
   <tr><td>3</td> <td>0xF0</td></tr>
   <tr><td>4</td> <td>16</td></tr>
   <tr><td>5</td> <td>0x01</td></tr>
   <tr><td>6</td> <td>Region Number (0 = yard region, 1..10 = forbidden
                      region)</td></tr>
   <tr><td>7,8</td> <td>x_left</td></tr>
   <tr><td>9,10</td> <td>y_bottom</td></tr>
   <tr><td>11,12</td> <td>width</td></tr>
   <tr><td>13,14</td> <td>height</td></tr>
   <tr><td>15</td> <td>Checksum Byte (XOR of all previous bytes)</td></tr>
 </table></center>

NetZero Platinum
No Banner Ads and Unlimited Access
Sign Up Today - Only $9.95 per month!
http://www.netzero.net

Re: [Doxygen-users] RE: Emails from two doxygen mailing lists...

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

On Fri, May 04, 2001 at 03:03:25PM -0400, Don McClimans wrote:
> I think we're supposed to be using the new one. I believe Dimitri has
> already said he will eventually shut down the old one.

XeT is the owner of the old list, so he decides how long the old
list will remain alive. But it will disappear, so I strongly suggest to use
the new list.

> Certainly those of us who want to use the digest feature would appreciate
> everyone moving to the SourceForge list. :)

That too is a nice bonus.

Regards,
  Dimitri