doxygen-users — List for users of doxygen

[Doxygen-users] compiling error in UNIX

[Yin, Z. <zy...@le...>]

I was trying to compile 1.2.9.1 in Solaris 2.5, the default compiler in
my solaris is gcc.

sh ./configure goes well. output message is in output.configure.

However, I kept got error message when I run "make". Error message is
included in output.make.

It seems in Makefile.qtools, the tag "AR" is not recognizable.

Is there anyway to solve this problem?

thanks

zhen

[Doxygen-users] XML output in Doxygen-1.2.9.1

[Tom H. <to...@op...>]

> Hi, 
> 
> My apologies if this has already been noted, but I have just played with
> enabling XML output in version 1.2.9.1, and I find that the XML is broken,
> with tags being closed in the wrong order, eg
> 
> <detaileddescription>
>   <para>
>     Blah blah...
>     <simplesect>
>       <title><bold>Returns: </bold></title>
>         More blah.
>     </para>
>   </simplesect>
>   <simplesect>
>     <title>
>       <para>
>         <bold>Warning: </bold>
>       </title>Even more blah.
>     </para>
>   </simplesect>        
> </detaileddescription>
> 
> The problem appears to be that the closing 'para' tag is emitted too late,
> there are two examples in the excerpt above. I could give a short example
> if required.
> 
>  Tom Harris, Software Engineer
>  Optiscan Imaging, 15-17 Normanby Rd, Notting Hill, Melbourne, Vic 3168,
> Australia
>  email to...@op...     ph +61 3 9538 3333  fax +61 3 9562 7742
> 
> This email may contain confidential information. If you have received this
> email in error, please delete it immediately,and inform us of the mistake
> by return email. Any form of reproduction, or further dissemination of
> this email is strictly prohibited.
> Also, please note that opinions expressed in this email are those of the
> author, and are not necessarily those of OptiScan Pty Ltd
> 
> 
> 
> -----Original Message-----
> From:	Dimitri van Heesch [SMTP:di...@st...]
> Sent:	Tuesday, 1 May 2001 0:01
> To:	do...@xe...
> Subject:	Doxygen-1.2.7 released
> 
> Hi,
> 
> I have just released version 1.2.7 of Doxygen. 
> 
> Sources and binaries for Linux and Windows are available from 
> http://www.doxygen.org/download.html
> 
> For a detailed list of what has changed since the last stable release look
> at:
> http://www.doxygen.org/changelog.html 
> 
> Enjoy,
>   Dimitri
> 
> P.S. I'm going move this announcement list to sourceforge to reduce the 
> amount of maintenance. If everything goes according plan, you should 
> receive a welcome message from the list as soon as you are added.
> 
> -----------------------------------------------------------
> Visit http://www.xeqt.com/doxygen/ for elist-administration

[Doxygen-users] Extra spacing between argument types and argument names in HTML output

[Geoff A. <gd...@us...>]

I've encountered a problem where there is large spacing between argument
types
and argument types in HTML output.  The problem occurs when there are
multiple
arguments and the text after the argument list is longer that the longest
argument type argument name pair.  Looking at the generated HTML, I believe
the
problem is due the use of colspan="2" for the text after the argument list.
Here is a example:

  /**
   * MyClass description.
   */
  class MyClass
  {
    /**
     * func1 description.
     */
  public:
    int func1( int a, int b, int c ) const
      throw( Exception1, Exception2, Exception3);
  };

The resulting table generated for func1 is

        <table cellpadding="0" cellspacing="0" border="0">
          <tr>
            <td class="md" nowrap valign="top">
  int MyClass::func1
            </td>
            <td class="md">(&nbsp</td>
            <td class="md">int          </td>
            <td class="mdname"> <em>a</em>,           </td>
          </tr>
          <tr>
            <td></td>
            <td></td>
            <td class="md">        <tr>
            <td></td>
            <td></td>
            <td class="md">int          </td>
            <td class="mdname"> <em>b</em>,           </td>
          </tr>
          <tr>
            <td></td>
            <td></td>
            <td class="md">        <tr>
            <td></td>
            <td></td>
            <td class="md">int          </td>
            <td class="mdname"> <em>c</em>          </td>
          </tr>
          <tr>
            <td></td>
            <td class="md">)&nbsp</td>
            <td class="md" colspan="2"> const  throw ( Exception1, Exception2, Exception3)          </td>
          </tr>

        </table>

One way to eliminate the extra spacing between the argument types and argument
names is to put the argument type and argument name pairs in a sub-table as
follows:

        <table cellpadding="0" cellspacing="0" border="0">
          <tr>
            <td class="md" nowrap valign="top">
  int MyClass::func1
            </td>
            <td class="md" valign="top">(&nbsp</td>
            <td>
              <table cellpadding="0" cellspacing="0" border="0">
                <td class="md">int          </td>
                <td class="mdname"> <em>a</em>,           </td>
              <tr>
                <td class="md">int          </td>
                <td class="mdname"> <em>b</em>,           </td>
              </tr>
              <tr>
                <td class="md">int          </td>
                <td class="mdname"> <em>c</em>          </td>
              </tr>
            </table>
          </td>
          <tr>
            <td></td>
            <td class="md">)&nbsp</td>
            <td class="md" colspan="2"> const  throw ( Exception1, Exception2, Exception3)          </td>
          </tr>

        </table>

BTW, I think that each argument other than the first has the following
unnecessary three lines of HTML:

              <td></td>
              <td></td>
              <td class="md">        <tr>

Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC

[Doxygen-users] Other MFC/VC preprocessing macros

[Steve S. <twe...@ya...>]

I would be glad to add to the list :)
Here's a few I had using COM/OLE:
"DECLARE_OLECREATE(class)= " \
"BEGIN_DISPATCH_MAP(class1, class2)= " \
"BEGIN_INTERFACE_MAP(class1, class2)= " \
"INTERFACE_PART(class, id, name)= " \
"END_INTERFACE_MAP()=" \
"DISP_FUNCTION(class, name, function, result, id)=" \
"END_DISPATCH_MAP()=" \
"IMPLEMENT_OLECREATE2(class, name, id1, id2, id3, id4,
id5, id6, id7, id8, id9, id10, id11)="


--- Dimitri van Heesch <di...@st...> wrote:
> On Thu, Aug 09, 2001 at 12:34:58PM +0200,
> Prikryl,Petr wrote:
> > Hi Dimitri,
> > 
> > It would be nice to put the PREDEFINED example for
> Microsoft MFC/ATL,
> > as shown below, somewhere into doxygen
> documentation.  I remember
> > that I once had also solve the problem.  MSVC
> compiler is quite widespread
> > concerning the development on MS Windows
> platforms, and it requires
> > some effort to capture the quantity of macros
> shown below.
> 
> Yes, I agree. I'll include this example in the
> preprocessor section of
> the docs. Thanks to Reyes for the hard work! Anyone
> who wants to add
> more macros to the list, please report them to me.
> 
> Regards,
>   Dimitri
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
>
http://lists.sourceforge.net/lists/listinfo/doxygen-users


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

[Doxygen-users] Some comments about templates.

[Ian B. <ian...@pr...>]

Hello All,
	I've been using Together C++ for some time now to generate
documentation from our sources.  Recently, however, I have moved to Doxygen
because it is cheaper and does a better job in most cases. The  only
challenge it has at the moment is dealing with templates. I have noticed
some discussion lately  about this subject and I thought it may be
interesting to let you know how Together goes about solving  this problem.

Templates, at least in my experience, are mainly used for collection classes
... lists, arrays, hash  tables etc. In this respect, showing the
associations in the collaboration diagram are more important to
understanding the code than showing the inheritance hierarchy. The problem
is that to write a parser that can draw a sensible collaboration diagram
from an optimised collection class template is a huge amount of  work.
Together allows the user to specify 'blueprints' ... these are basically
string matching expressions  which give the parser hints as to how to draw
the collaboration graphs. I haven't looked into the code of  Doxygen, so I
don't know if this type of thing would be possible to integrate. It may,
however, provide a  quicker method of documenting template hierarchies and
collaborations than straight code parsing. In the  case of the collaboration
diagrams it would also provide a method of describing what the collection
holds without the extraneous template implementation details also being
shown.

I have attached a section of my Together configuration file wich gives
Together the information necessary to document the MFC Collection Classes.
It's fairly self explanatory and should help give you some idea about what
I'm talking about.

For more information, download the trial version of Together and have a play
... Doxygen does most things  better, but it's still an interesting
comparison. (http://www.togethersoft.com)

Ian Brown

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

#
# Parser's blueprints are defined with only one pattern string and without
quotes.
# In addition to codegen blueprints, you can use %Any% in patterns.
#  %Any% - any token.
# Each attribute declaration or design comment is compared against the
blueprint pattern
#  and if recognized, forms a link of the corresponding type.
# NOTE: the first matched blueprint is used.
# Additional properties (tags) can be defined as sub-property for particular
blueprint.
# NOTE: tag values directly specified in design comments override the ones
from blueprint.
#
# Add some defines for MFC containers...

parser.cpp.blueprint.link.Association from Typed pointer list =
CTypedPtrList<CPtrList, %dst%*> %Name%
parser.cpp.blueprint.link.Association from Typed pointer
list.supplierCardinality = "0..*"

parser.cpp.blueprint.link.Association from Typed pointer array =
CTypedPtrArray<CPtrArray, %dst%*> %Name%
parser.cpp.blueprint.link.Association from Typed pointer
array.supplierCardinality = "0..*"

parser.cpp.blueprint.link.Aggregation from CArray = CArray<%dst%, %dst%&>
%Name%
parser.cpp.blueprint.link.Aggregation from CArray.link = "aggregation"
parser.cpp.blueprint.link.Aggregation from CArray.supplierCardinality =
"0..*"

parser.cpp.blueprint.link.Aggregation from CList = CList<%dst%, %dst%&>
%Name%
parser.cpp.blueprint.link.Aggregation from CList.link = "aggregation"
parser.cpp.blueprint.link.Aggregation from CList.supplierCardinality =
"0..*"

# NOTE: uncomment the following lines to treat pointer to class as
aggregation (not recommended).
;parser.cpp.blueprint.link.Aggregation from pointer = %dst% * %Name%
;parser.cpp.blueprint.link.Aggregation from pointer.link = "aggregation"
;parser.cpp.blueprint.link.Aggregation from pointer.supplierCardinality =
"1"

parser.cpp.blueprint.link.Association from pointer = %dst% * %Name%
parser.cpp.blueprint.link.Association from pointer.supplierCardinality =
"0..1"

parser.cpp.blueprint.link.Association from pointer_ = %Any% %dst% * %Name%
parser.cpp.blueprint.link.Association from pointer_.supplierCardinality =
"0..1"

parser.cpp.blueprint.link.Association from reference = %dst%& %Name%
parser.cpp.blueprint.link.Association from reference.supplierCardinality =
"1"

# NOTE: uncomment the following lines to treat template container of
pointers to class as aggregation  (not recommended).
;parser.cpp.blueprint.link.Aggregation from template of pointers =
%Any%<%dst%*> %Name%
;parser.cpp.blueprint.link.Aggregation from template of pointers.link =
"aggregation"
;parser.cpp.blueprint.link.Aggregation from template of
pointers.supplierCardinality = "1..*"

parser.cpp.blueprint.link.Association from template of pointers =
%Any%<%dst%*> %Name%
parser.cpp.blueprint.link.Association from template of
pointers.supplierCardinality = "0..*"

# NOTE: to threat aggreration as composition comment line with "aggregation"
and uncomment one with  "aggregationByValue"
parser.cpp.blueprint.link.Aggregation = %dst% %Name%
parser.cpp.blueprint.link.Aggregation.link = aggregation
;parser.cpp.blueprint.link.Aggregation.link = "aggregationByValue"

# NOTE: to threat aggreration as composition comment line with "aggregation"
and uncomment one with  "aggregationByValue"
parser.cpp.blueprint.link.Aggregation from template = %Any%<%dst%> %Name%
parser.cpp.blueprint.link.Aggregation from template.link = "aggregation"
;parser.cpp.blueprint.link.Aggregation from template.link =
"aggregationByValue"
parser.cpp.blueprint.link.Aggregation from template.supplierCardinality =
"1..*"

[Doxygen-users] Doxygen-1.2.9-20010812 in CVS

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

Hi,

Here is the changelog for this week's release:
------------------------------------------------------------------------------
+ BUG: Fix compile problem for the Irix compiler (thanks to Dirk Reiners)
+ BUG: Some generated &nsbp; where missing a ; in the html output.
       For some browsers this resulted in argument types & names being glued
       together.
+ BUG: The heading of parameter and return value lists was not bold anymore in
       the HTML output.
+ BUG: "Reimplemented to/from" member links now work between template base
       classes and their derived classes.
+ BUG: Not all documented templates class were regarded as documented
       (unless EXTRACT_ALL was set to YES).
+ ADD: Relations between templates and their instances are now visualized
       in the inheritance and collaboration graphs. Can be disabled
       by setting TEMPLATE_RELATIONS to NO in the config file.
+ BUG: Fixed recursive lock-up problem for recursive templates of the form:
       template<class T> class A : public A<typename T::B> {}
+ BUG: The labels in the alphabetical list were broken when namespaces were 
       used.
+ BUG: An error was given for import statements in Java sources.
+ ADD: A Java package can now be documented using a comment block containing a
       @package command or by putting a documentation block in front of a
       package statement.
------------------------------------------------------------------------------
Enjoy,
  Dimitri

Re: [Doxygen-users] Help with preprocessing macros

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

On Thu, Aug 09, 2001 at 12:34:58PM +0200, Prikryl,Petr wrote:
> Hi Dimitri,
> 
> It would be nice to put the PREDEFINED example for Microsoft MFC/ATL,
> as shown below, somewhere into doxygen documentation.  I remember
> that I once had also solve the problem.  MSVC compiler is quite widespread
> concerning the development on MS Windows platforms, and it requires
> some effort to capture the quantity of macros shown below.

Yes, I agree. I'll include this example in the preprocessor section of
the docs. Thanks to Reyes for the hard work! Anyone who wants to add
more macros to the list, please report them to me.

Regards,
  Dimitri

RE: [Doxygen-users] Help with preprocessing macros

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

Hi Dimitri,

It would be nice to put the PREDEFINED example for Microsoft MFC/ATL,
as shown below, somewhere into doxygen documentation.  I remember
that I once had also solve the problem.  MSVC compiler is quite widespread
concerning the development on MS Windows platforms, and it requires
some effort to capture the quantity of macros shown below.

Thanks,
  Petr

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

> -----Original Message-----
> From:	Reyes Ponce [SMTP:Re...@na...]
> Sent:	Tuesday, August 07, 2001 6:36 PM
> To:	dox...@li...
> Subject:	Re: [Doxygen-users] Help with preprocessing macros
> 
> This is what I've come up with so far. I started with the ATL list in the
> FAQ and added to it as I've encountered more problems. Most of this is MFC
> and ATL stuff. Your milage may vary...
> 
> PREDEFINED           = "DECLARE_INTERFACE(name)=class name" \
>                        "STDMETHOD(result,name)=virtual result name" \
>                        "PURE= = 0" \
>                        THIS_= \
>                        THIS= \
>                        DECLARE_REGISTRY_RESOURCEID=// \
>                        DECLARE_PROTECT_FINAL_CONSTRUCT=// \
>                        "DECLARE_AGGREGATABLE(Class)= " \
>                        "DECLARE_REGISTRY_RESOURCEID(Id)= " \
>                        DECLARE_MESSAGE_MAP = \
>                        BEGIN_MESSAGE_MAP=/* \
>                        END_MESSAGE_MAP=*/// \
>                        BEGIN_COM_MAP=/* \
>                        END_COM_MAP=*/// \
>                        BEGIN_PROP_MAP=/* \
>                        END_PROP_MAP=*/// \
>                        BEGIN_MSG_MAP=/* \
>                        END_MSG_MAP=*/// \
>                        BEGIN_PROPERTY_MAP=/* \
>                        END_PROPERTY_MAP=*/// \
>                        BEGIN_OBJECT_MAP=/* \
>                        END_OBJECT_MAP()=*/// \
>                        DECLARE_VIEW_STATUS=// \
>                        "STDMETHOD(a)=HRESULT a" \
>                        "ATL_NO_VTABLE= " \
>                        "__declspec(a)= " \
>                        BEGIN_CONNECTION_POINT_MAP=/* \
>                        END_CONNECTION_POINT_MAP=*/// \
>                        "DECLARE_DYNAMIC(class)= " \
>                        "IMPLEMENT_DYNAMIC(class1, class2)= " \
>                        "DECLARE_DYNCREATE(class)= " \
>                        "IMPLEMENT_DYNCREATE(class1, class2)= " \
>                        "IMPLEMENT_SERIAL(class1, class2, class3)= " \
>                        "DECLARE_MESSAGE_MAP()= " \
>                        TRY=try \
>                        "CATCH_ALL(e)= catch(...)" \
>                        END_CATCH_ALL= \
>                        "THROW_LAST()= throw"\
>                        "RUNTIME_CLASS(class)=class" \
>                        "MAKEINTRESOURCE(nId)=nId" \
>                        "IMPLEMENT_REGISTER(v, w, x, y, z)= " \
>                        "ASSERT(x)=assert(x)" \
>                        "ASSERT_VALID(x)=assert(x)" \
>                        "TRACE0(x)=printf(x)" \
>                        "OS_ERR(A,B)={ #A, B }" \
>                        __cplusplus
> 
[the end]

[Doxygen-users] Preprocessing Issues

[<joh...@uk...>]

Hi again

I'm working with doxygen on a large C code project which makes heavy use of
preprocessor conditionals and macro expansion.  Doxygen does a wonderful
job, but this project has exposed a weakness in the preprocessor area:
doxygen deposits the results of preprocessing in the header files instead
of in the source (.c) files where they logically belong.

 Consider the following source file fragment:
   #define ONE
   #include "header.h"
   #undef ONE
   #define TWO
   #include "header.h"
   #undef TWO
header.h may recursively include other headers affected by ONE and TWO.
This technique is used in the project I'm working on to generate structs,
initialized variables etc which are particular to the source file driving
the inclusion, not to any header file. Another source file might include
the same header to achieve a quite different outcome.

In a specific case in the project I'm concerned with, a struct array
variable definition and initializer is built from a number of headers when
included in a particular source file. I want that variable and initializer
to appear in the source file documentation (with a reference to the
header), not in the header documentation where doxygen currently puts it.
Another issue here is that the preprocessor-generated initializer contains
lots of blank lines which I'm currently removing from the html files with a
script. I had to set MAX_INITIALIZER_LINES to a very large number to see it
at all. I've started to delve into the doxygen source to try to fix these
problems. Any advice appreciated.

John Storrs

[Doxygen-users] templated hierarchy in 1.2.9.1

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

Hi
I've downloaded 1.2.9.1. Indeed the template crash I experienced with 1.2.9
disappeared. Thanks Dimitri!

However, my documented templated hierarchies are still not complete. I
didn't try the HAVE_DOT=YES yet, but from the email I gathered that this
should now give the same hierarchy as with HAVE_DOT=NO).

Examples:

Using this input:
-----------------
//! B
template <int n, class A> class B {};
//! B2
template <class A> class B2 : public B<2,A> {};

//! C
template <class A> class C {};
//! C2
template <class A> class C2 : public C<A>{};

//! D
class D {};
//! E
template <class Base> class E: public Base{};
//! F
class F : E<D> {};
//! fromD
template <class A> class fromD : D {};
-----------------


doxygen generate now the following hierarchy


-----------------
B< n, A >
B2< A >
C< A >
       C2< A >
D
       fromD< A >
E< Base >
F
-----------------

doxygen does not show that B2 is derived from B, neither that F is derived
from E<D> (both of which 1.2.8.1 *did* show), nor that F is derived from D
((which 1.2.8.1 did not show either).


Kris

Re: [Doxygen-users] support for K&R-style function arguments

[John S. <joh...@se...>]

Zhen Yin wrote:
> 
> So far doxygen doesn't support for K&R-style function arguments. I was
> doing a project which applies Doxygen to a large development tree. Many
> source codes have K&R-style function arguments, such as:
>         char *  xcalloc(nelem, elsize)
>              lg_size_t nelem;
>              lg_size_t elsize;
>             {......}
> 
> For a series of functions which use above format, doxygen will only
> extract the first one, i.e., in "Function Documentation", it only lists
> the first function.
> 
> Does anyone have any experience about temporarily handling this problem?
> 

I'd suggest getting hold of a K&R-to-ANSI converter (I believe GNU
supply one with their compilers) and use it as an INPUT_FILTER for
Doxygen.

Good luck,

John

[Doxygen-users] support for K&R-style function arguments

[Zhen Y. <zy...@le...>]

So far doxygen doesn't support for K&R-style function arguments. I was
doing a project which applies Doxygen to a large development tree. Many
source codes have K&R-style function arguments, such as:
        char *  xcalloc(nelem, elsize)
             lg_size_t nelem;
             lg_size_t elsize;
            {......}

For a series of functions which use above format, doxygen will only
extract the first one, i.e., in "Function Documentation", it only lists
the first function.

Does anyone have any experience about temporarily handling this problem?

thanks

zhen

[Doxygen-users] Documentation Blocks in Macros

[<joh...@uk...>]

Hi there

I'm using Doxygen with great effect to document and understand a large C
software project I'm porting. I find the macro expansion capability very
useful, as a lot of C structures are generated through macros. The struct
macro source is well commented, but the preprocessor removes the comments
when a struct is generated by macro expansion (the same behaviour as gcc's
cpp with the -C flag). How can I arrange that the comments are included in
the macro expansion so they are brought into the documentation? I've
thought of mapping /* to xxxxxx and */ to yyyyyy in an input filter which
would do the trick, but there is no post-preprocessing filter to put the
comments back again before further processing.

Another small point relating to macro expansion. The Doxygen preprocessor
doesn't expand macros in #include directives (eg #include SPECIAL where
SPECIAL = "myfile").

John Storrs

[Doxygen-users] Hiding classes / files in doxygen output

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

First: I tried to search the archive, but searching failed. So please
forgive me if I ask a FAQ.

I have a couple of classes that are kind of "internal", i.e. they are
of interest for someone who works on _this_ module, but not for "users"
of the module. I would like to have two different doxyfiles that
do the following:
- file 1 generates docs for all classes, also the "internal" ones
- file 2 only generates docs for the "non-internal" classes

I tried the following:

<code>
    /*! \if ModuleInternals
	\brief (short description)

       (more detailed description)
	\endif
     */
    class MyClass
    {
      public:

        /*! \if ModuleInternals
            \brief Constructor

            \endif
         */
        MyClass (...)
</code>

_without_ including "ModuleInternals" in ENABLED_SECTIONS

and

<code>
    /*! \internal
	\brief (short description)

       (more detailed description)
     */
    class MyClass
    {
      public:

        /*! \internal
            \brief Constructor
         */
        MyClass (...)
</code>

together with INTERNAL_DOCS = NO

However, both approaches generated pages and documentation for the
class. Did I miss an option that changes the behaviour? Is this a
bug and if it is, is it fixed in the latest version (I use V 1.2.0)?

--
-- -----------------------------------------------------------------
-- 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] Alphabetical List

[Pablo A. <alv...@te...>]

Hi all,

in the last version (1.2.9.1) there is some "new" behaviour with the
alphabetical list: now it sorts _everything_ alphabetical, with the
problem that if your whole proyect is contained in a namespace (for
example std), then you'll get now only one letter "S" in the mentioned
list.  Is it possible to make a configuration option that changes this
new functionality into the old fashion?, or even better, that allow us
to tell doxygen it should ignore one specific namespace when generating
the alphabetical list?

Thanks,

Pablo

-- =

Dipl.-Ing. Pablo Alvarado   <alv...@te...>
Lehrstuhl f=FCr Technische Informatik,    RWTH-Aachen
Ahornstr.55               Phone : ++49 241 80 23635
D-52074 Aachen            Fax   : ++49 241 80 22308

[Doxygen-users] Output format of brief comments

[<mle...@wo...>]

Hi there.
I've just recently started using doxygen and I was wondering if I can control
where doxygen puts the brief comments of a struct? I'm writing documentation
for a struct, and a brief for each member. Doxygen puts the brief on the
next line instead of beside the member. Example:

typedef struct {
 int blah ///<Blah brief
}

Produces something like:
 int blah
       Blah brief

What I would like is somehting like:
 int blah  Blah brief

Is that possible?
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen

Re: [Doxygen-users] problem with doxywizard

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

On Tue, Aug 07, 2001 at 06:57:13PM +0200, Holger Mueller wrote:
> Hi,
> 
> I compiled and installed doxygen 1.2.9 on RH 7.1 Linux.
> 
> If I open my doxygen file with doxywizard I get the following warning
> message:
> 
>   Cannot open or read input Doxyfile!
> 
> I also created a new Doxyfile (with doxygen -g) and got the same
> message. After quiting this warning I see that not all options are
> loaded. Does someone else see this behavior?

Anyone who upgarded to v1.2.9.1 shouldn't ;-)

Regards,
  Dimitri

[Doxygen-users] problem with doxywizard

[Holger M. <hmu...@si...>]

Hi,

I compiled and installed doxygen 1.2.9 on RH 7.1 Linux.

If I open my doxygen file with doxywizard I get the following warning
message:

  Cannot open or read input Doxyfile!

I also created a new Doxyfile (with doxygen -g) and got the same
message. After quiting this warning I see that not all options are
loaded. Does someone else see this behavior?

Holger

Re: [Doxygen-users] Help with preprocessing macros

[Reyes P. <Re...@na...>]

This is what I've come up with so far. I started with the ATL list in the
FAQ and added to it as I've encountered more problems. Most of this is MFC
and ATL stuff. Your milage may vary...

PREDEFINED           = "DECLARE_INTERFACE(name)=class name" \
                       "STDMETHOD(result,name)=virtual result name" \
                       "PURE= = 0" \
                       THIS_= \
                       THIS= \
                       DECLARE_REGISTRY_RESOURCEID=// \
                       DECLARE_PROTECT_FINAL_CONSTRUCT=// \
                       "DECLARE_AGGREGATABLE(Class)= " \
                       "DECLARE_REGISTRY_RESOURCEID(Id)= " \
                       DECLARE_MESSAGE_MAP = \
                       BEGIN_MESSAGE_MAP=/* \
                       END_MESSAGE_MAP=*/// \
                       BEGIN_COM_MAP=/* \
                       END_COM_MAP=*/// \
                       BEGIN_PROP_MAP=/* \
                       END_PROP_MAP=*/// \
                       BEGIN_MSG_MAP=/* \
                       END_MSG_MAP=*/// \
                       BEGIN_PROPERTY_MAP=/* \
                       END_PROPERTY_MAP=*/// \
                       BEGIN_OBJECT_MAP=/* \
                       END_OBJECT_MAP()=*/// \
                       DECLARE_VIEW_STATUS=// \
                       "STDMETHOD(a)=HRESULT a" \
                       "ATL_NO_VTABLE= " \
                       "__declspec(a)= " \
                       BEGIN_CONNECTION_POINT_MAP=/* \
                       END_CONNECTION_POINT_MAP=*/// \
                       "DECLARE_DYNAMIC(class)= " \
                       "IMPLEMENT_DYNAMIC(class1, class2)= " \
                       "DECLARE_DYNCREATE(class)= " \
                       "IMPLEMENT_DYNCREATE(class1, class2)= " \
                       "IMPLEMENT_SERIAL(class1, class2, class3)= " \
                       "DECLARE_MESSAGE_MAP()= " \
                       TRY=try \
                       "CATCH_ALL(e)= catch(...)" \
                       END_CATCH_ALL= \
                       "THROW_LAST()= throw"\
                       "RUNTIME_CLASS(class)=class" \
                       "MAKEINTRESOURCE(nId)=nId" \
                       "IMPLEMENT_REGISTER(v, w, x, y, z)= " \
                       "ASSERT(x)=assert(x)" \
                       "ASSERT_VALID(x)=assert(x)" \
                       "TRACE0(x)=printf(x)" \
                       "OS_ERR(A,B)={ #A, B }" \
                       __cplusplus





----- Original Message -----
From: "Steve Santacroce" <twe...@ya...>
To: <dox...@li...>
Sent: Tuesday, August 07, 2001 10:03 AM
Subject: [Doxygen-users] Help with preprocessing macros


> I am having trouble understanding just how to get the
> auto-generated MFC macros to be ignored by doxygen. I
> don't like the idea of just inserting a semicolon at
> the end of the macros, because we need to keep it as
> simple as possible for all the coders. I read the
> preprocessing section of the help, but I think I am
> more confused now than I was before. An example would
> help me greatly, one that directly applies to me.
> Given these two macros:
>
> DECLARE_MESSAGE_MAP()
> DECLARE_OLECREATE(multiple class names here)
>
> How would I go about having Doxygen get around them?
> Thank you for your time and help!
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] Help with preprocessing macros

[Steve S. <twe...@ya...>]

I am having trouble understanding just how to get the
auto-generated MFC macros to be ignored by doxygen. I
don't like the idea of just inserting a semicolon at
the end of the macros, because we need to keep it as
simple as possible for all the coders. I read the
preprocessing section of the help, but I think I am
more confused now than I was before. An example would
help me greatly, one that directly applies to me.
Given these two macros:

DECLARE_MESSAGE_MAP()
DECLARE_OLECREATE(multiple class names here)

How would I go about having Doxygen get around them?
Thank you for your time and help!

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Doxygen-users] excluding classes, function defs, etc

[Raimund K. <rk...@or...>]

RTFM - FAQ #4
 
> Is there a way to *exclude* definitions or decalarations
> from the docs using Doxygen? On a class-by-class basis?

-- 
Raimund Klein <kl...@or...>
Orthogon GmbH, Hastedter Osterdeich 222, D-28207 Bremen

[Doxygen-users] excluding classes, function defs, etc

[Eric R. <eri...@ya...>]

Is there a way to *exclude* definitions or decalarations
from the docs using Doxygen? On a class-by-class basis?

I have header files with classes that I do not want to appear
at all in the documentation, neither as documented links or
undocumented (black) links, which is what I get when I do not
put any doc string before the class.

I have lots of template structs with specializations - the docs
get pretty unreadable with all those, and I do not want to confuse
the library users.

It is not clear how \internal works exactly.

would \if work? Or would I still get an entry for the
class/function/whatever?

-Eric


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Doxygen-users] Doxygen-1.2.9.1 in CVS

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

Hi,

There were some bugs in last weeks release, which I hope to have fixed now:
----------------------------------------------------------------------------
+ BUG: The .spec file still assumed the --with-xmlgen switch was available.
+ BUG: Template instances caused double entries in the class list 
       (in LaTeX) and broke RTF output.
+ BUG: \if and \endif can now be used to make structural commands like
       \brief, \ingroup, and \defgroup conditional.
+ ADD: Added three new conditional commands: \ifnot, \else and \elseif
       (thanks to Fabian Cenedese).
+ BUG: The "const" in "func(B * const)" was parsed as a variable name.
+ BUG: Template specializations of the form A<N::C> where not handled
       properly.
+ BUG: Putting \relates in a function documentation block that was 
       within a namespace, while referring to another namespace did not work.
+ BUG: Doxywizard always complained it could not read the config file.
+ BUG: Doxywizard did not properly update boolean and integer values.
+ BUG: Fixed recursive lock-up problem when recursive templates were used.
+ BUG: LaTeX output was broken when PDF_HYPERLINKS was enabled and templates
       were used.
+ BUG: Private friends were hidden even though friends have no access control.
+ BUG: Argument matching was sensitive to spaces in some cases.
+ BUG: Bug/test/todo item in class members did not always result in the
       generation of the list. 
+ CHG: Bug/test/todo Items of members are now grouped 
       together with their compound.
----------------------------------------------------------------------------
Enjoy,
  Dimitri

[Doxygen-users] Giant GIF files -- Is there a way to limit size

[Greg S. <gd...@sa...>]

On our project, we have a few include files which are globally included
by (almost) every class.  These are used to define some generic types
such as Real and Int.  The problem occurs when doxygen/dot tries to
generate the include and dependency graphs.  One GIF is about 12Meg and
several others are around 2Meg and take upto 30-40 minutes to generate.
The GIFs are also unreadable containing some very small black dots
representing the text.

Is there a way to tell doxygen and/or dot to skip the dependency and
include graphs for these 'global' include files?

Thanks, Greg

[Doxygen-users] template crash with Doxygen-1.2.9

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

Hi,

I've just installed 1.2.9 and ran it on our source code (on a Windows NT 4.0
sp5 machine). It crashed with the following
"exception unknown software exception (0xc00000fd) occured in the
application at location 0x77f6468f".
When I hit the 'Cancel' button to launch the MCVC debugger, I get the dialog
box:
"Unhandled exception in doxygen.exe (NTDLL.DLL) 0xC00000FD: Stack Overflow."
The crash actually occured at address 004EBDD3 in doxygen.exe.


The last few lines on my screen are

---------------
Freeing input...
Building group list...
Building namespace list...
Building file list...
Building class list...
Building example list...
Searching for documented variables...
Building member list...
Searching for friends...
Searching for documented defines...
Computing template instances...
----------------

Suggestions? (Sorry, no time whatsover to compile doxygen and run it in
debug mode, I could send you the source files Dimitri if you want).

All the best,

Kris Thielemans
(kri...@ic...)
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