doxygen-users — List for users of doxygen

[Doxygen-users] Apple's NS_ENUM Macro

[Marshall C. D. <cma...@ni...>]

Folks,

I have a file with a bunch of typedefs.

I'm using Apple's recommended method of defining a NS_ENUM macro to declare enumeration typedefs.

Normally, I'd define a typedef like so:

typedef enum
{
MyCoolEnum_Value1 = 1,
MyCoolEnum_Value2 = 2
} MyCoolEnum;

However, Apple (Objective C 2.0, really) has created a macro that allows you to assign a datatype to the enum, like so:

typedef NS_ENUM ( uInt_16, MyCoolEnum )
{
MyCoolEnum_Value1 = 1,
MyCoolEnum_Value2 = 2
};

Unfortunately, when Doxygen hits this, it sets the enum as "NS_ENUM", instead of "MyCoolEnum".

Is there any way for me to get Doxygen to recognize the enum, or should I discard the Apple method, and use the plain old-fashioned C++ enum?




[http://download2.nikon.net/images/logo/bsymbol.gif]
Christopher D Marshall
Sr. Software Development Manager

Nikon Inc.
1300 Walt Whitman Road
Melville NY 11747-3064

Office: 631-547-4334    Fax: 631-547-0361

cma...@ni...<mailto:cma...@ni...>




www.nikonusa.com




[http://download2.nikon.net/images/logo/COOLPIX_A_EmailTag_Rv2.gif] <http://www.nikonusa.com/en/Nikon-Products/Product/Compact-Digital-Cameras/26423/COOLPIX-A.html?cid=eml-0613-coolpixa-signature>








CONFIDENTIAL:
This e-mail including any attachments is intended only for the party or parties to whom it is addressed and may contain information which is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, copying, or printing of any information contained in or attached to this e-mail is STRICTLY PROHIBITED and may constitute a breach of confidentiality and/or privilege. If you have received this e-mail in error, please notify immediately the sender by reply e-mail and then delete this e-mail and any attachments in their entirety from your system. Thank you. This e-mail message including any attachments is believed to be free of any viruses; however, it is the sole responsibility of the recipient to ensure that it is virus free, and Nikon does not accept any responsibility for any loss, disruption or damage to your data or computer system which may occur in connection with this e-mail including any attachments.

[Doxygen-users] the first major release-candidate of Moritz 2

[<Eck...@t-...>]

Hello Everybody.

After 4 years of refactoring the first milestone having the next major 
release of Moritz the nassi-shneiderman generator for Doxygen is nearly 
reached. The completely new developed Moritz2 presents with the 
demo-version 8 its first release-candidate (under 
https://www.moritz.sourceforge.net or 
https://www.sourceforge.net/projects/moritz/ use "Browse All Files").

Most of the features already known from the older Moritz1 are still 
available:
1. Generation of Nassi-Shneiderman diagrams based on HTML.
2. Control of the diagrams by using special commands inside of comments.
Furthermore new features are available:
1.Generation of uml-like activity-diagrams based on dot( 
http://www.graphviz.org ).
2.Support of more programming-languages (C/Cpp, Python, Matlab, Pascal)

Another new feature is an own parser. Thus Moritz can be used 
independently from other tools to generate its output. Furthermore the 
xml-output created by the parser represents the parser-tree of the 
source in other words the algorithm and not the document-structure.
The new release contains one windows-distribution and one 
linux-distribution together with documentation-files (please use "Browse 
All Files" and ignore the download-proposal).

To use Moritz for different source projects an user-project is 
available, that contains only the needed output-folders and templates 
for the basic configurations. It should be copied near to the 
source-project and combined with the distribution (please refer the page 
User-Project  of the documentation)

If you want to build the binaries (abc2xml and xml2abc) by your self, 
you will find the sources of xml2abc in the current release of Moritz 
and the sources of abc2xml in the current release of its partner-project 
MuLanPa (under https://www.mulanpa.sourceforge.net or 
https://www.sourceforge.net/projects/mulanpa/ )

If you have questions or doubts you will find in both projects forum-places:
Source-Parser:
  Discussion: https://sourceforge.net/p/mulanpa/discussion/
  Bugs: https://sourceforge.net/p/mulanpa/tickets/
Diagram-Generator:
  Discussion: https://sourceforge.net/p/moritz/discussion/
  Bugs: https://sourceforge.net/p/moritz/bugs/

Even the development has reached a nearly stable point this means not 
that it is perfect. Thus please don't hesitate to use the forum.

Best Regards,
                  Eckard Klotz.

[Doxygen-users] exclude if() and switch() in php

[Miguel A. G. <mig...@gm...>]

hello

Im using doxygen to document my php code.. Im getting this warning:

Warning: documented function `switch' was not declared or defined.

while trying to generate code for a file that has the "switch()" php 
instruction.. I think that doxygen understand if() and switch() as if 
they were calls to user-defined functions

if I put:
EXCLUDE_SYMBOLS        =     if \
                             switch

then doxygen dont make "if()" and "switch()" clickeable in the 
documentation, but Im still getting the error

I can use /cond .. /endcond, but I would have to fix a lot of files

can you help me?

thank you

Re: [Doxygen-users] Current Version DoxyApp Not Building

[Kevin N. <kne...@si...>]

One change...  to solve the problem permanently, the change below needs 
to be made in the doxyapp.pro file, as the Makefile.doxyapp is generated 
during the build process.  I found this out by running make clean, and 
seeing my changes removed.

Kevin

On 9/13/13 8:49 AM, Kevin Nesmith wrote:
> Thanks for the quick fix.  I had one more issue, but was able to solve...
>
> g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools 
> -I../../src -o ../../objects/doxyapp.o doxyapp.cpp
> g++ -g -o ../../bin/doxyapp ../../objects/doxyapp.o  -L../../lib 
> -L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg
> ../../lib/libqtools.a(qthread_unix.o): In function 
> `QThreadPrivate::start(void*)':
> qthread_unix.cpp:(.text+0x148): undefined reference to 
> `pthread_testcancel'
> ../../lib/libqtools.a(qthread_unix.o): In function `QThread::start()':
> qthread_unix.cpp:(.text+0x1dc): undefined reference to `pthread_sigmask'
> qthread_unix.cpp:(.text+0x22a): undefined reference to `pthread_create'
> qthread_unix.cpp:(.text+0x2a0): undefined reference to `pthread_sigmask'
> qthread_unix.cpp:(.text+0x2b4): undefined reference to 
> `pthread_attr_setstacksize'
> ../../lib/libqtools.a(qthread_unix.o): In function 
> `QThread::terminate()':
> qthread_unix.cpp:(.text+0x30b): undefined reference to `pthread_cancel'
> collect2: error: ld returned 1 exit status
> gmake[2]: *** [../../bin/doxyapp] Error 1
>
> Turns out the linking call was missing "-lpthread".  I added this to 
> the end of the LIBS line in the Makefile.doxyapp.  This solved the 
> compiling problem.
>
> old:
> LIBS    =   -L../../lib -L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg
>
> new:
> LIBS    =   -L../../lib -L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg 
> -lpthread
>
> Thanks again,
>
> Kevin
>
>
> On 9/13/13 8:31 AM, Dimitri van Heesch wrote:
>> Hi Kevin,
>>
>> On Sep 11, 2013, at 19:58 , Kevin Nesmith <kne...@si...> wrote:
>>> I have tried the latest source download, version 1.8.5 and the latest
>>> version in git. I have run the configure with the doxyapp parameter. 
>>> But
>>> when the compiler gets to the doxyapp build, I receive the following
>>> errors...
>>>
>>> g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools -I../../src
>>> -o ../../objects/doxyapp.o doxyapp.cpp
>>> doxyapp.cpp: In function ‘void findXRefSymbols(FileDef*)’:
>>> doxyapp.cpp:114:66: error: cannot allocate an object of abstract type
>>> ‘XRefDummyCodeGenerator’
>>> doxyapp.cpp:41:7: note: because the following virtual functions are 
>>> pure
>>> within ‘XRefDummyCodeGenerator’:
>>> In file included from doxyapp.cpp:31:0:
>>> ../../src/outputgen.h:100:18: note: virtual void
>>> CodeOutputInterface::writeTooltip(const char*, const DocLinkInfo&, 
>>> const
>>> char*, const char*, const SourceLinkInfo&, const SourceLinkInfo&)
>>> doxyapp.cpp:122:19: error: no matching function for call to
>>> ‘ParserInterface::parseCode(XRefDummyCodeGenerator&, int, QCString,
>>> const bool&, int, FileDef*&)’
>>> doxyapp.cpp:122:19: note: candidate is:
>>> In file included from doxyapp.cpp:32:0:
>>> ../../src/parserintf.h:102:18: note: virtual void
>>> ParserInterface::parseCode(CodeOutputInterface&, const char*, const
>>> QCString&, SrcLangExt, bool, const char*, FileDef*, int, int, bool,
>>> MemberDef*, bool, Definition*)
>>> ../../src/parserintf.h:102:18: note: no known conversion for argument 4
>>> from ‘const bool’ to ‘SrcLangExt’
>>>
>>>
>>> I don't believe this is an issue with the version of compiler or 
>>> version
>>> of Linux.
>> Indeed. The API changed and the doxyapp wasn't updated in the process.
>> I've just pushed a fix to GitHub:
>> https://github.com/doxygen/doxygen/commit/b07832a11606e3d1b488ee2ab4ec34bb6ccb7921 
>>
>>
>> Regards,
>>    Dimitri
>>
>

Re: [Doxygen-users] Current Version DoxyApp Not Building

[Kevin N. <kne...@si...>]

Thanks for the quick fix.  I had one more issue, but was able to solve...

g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools -I../../src 
-o ../../objects/doxyapp.o doxyapp.cpp
g++ -g -o ../../bin/doxyapp ../../objects/doxyapp.o  -L../../lib 
-L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg
../../lib/libqtools.a(qthread_unix.o): In function 
`QThreadPrivate::start(void*)':
qthread_unix.cpp:(.text+0x148): undefined reference to `pthread_testcancel'
../../lib/libqtools.a(qthread_unix.o): In function `QThread::start()':
qthread_unix.cpp:(.text+0x1dc): undefined reference to `pthread_sigmask'
qthread_unix.cpp:(.text+0x22a): undefined reference to `pthread_create'
qthread_unix.cpp:(.text+0x2a0): undefined reference to `pthread_sigmask'
qthread_unix.cpp:(.text+0x2b4): undefined reference to 
`pthread_attr_setstacksize'
../../lib/libqtools.a(qthread_unix.o): In function `QThread::terminate()':
qthread_unix.cpp:(.text+0x30b): undefined reference to `pthread_cancel'
collect2: error: ld returned 1 exit status
gmake[2]: *** [../../bin/doxyapp] Error 1

Turns out the linking call was missing "-lpthread".  I added this to the 
end of the LIBS line in the Makefile.doxyapp.  This solved the compiling 
problem.

old:
LIBS    =   -L../../lib -L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg

new:
LIBS    =   -L../../lib -L../../lib -ldoxygen -lqtools -lmd5 -ldoxycfg 
-lpthread

Thanks again,

Kevin


On 9/13/13 8:31 AM, Dimitri van Heesch wrote:
> Hi Kevin,
>
> On Sep 11, 2013, at 19:58 , Kevin Nesmith <kne...@si...> wrote:
>> I have tried the latest source download, version 1.8.5 and the latest
>> version in git. I have run the configure with the doxyapp parameter. But
>> when the compiler gets to the doxyapp build, I receive the following
>> errors...
>>
>> g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools -I../../src
>> -o ../../objects/doxyapp.o doxyapp.cpp
>> doxyapp.cpp: In function ‘void findXRefSymbols(FileDef*)’:
>> doxyapp.cpp:114:66: error: cannot allocate an object of abstract type
>> ‘XRefDummyCodeGenerator’
>> doxyapp.cpp:41:7: note: because the following virtual functions are pure
>> within ‘XRefDummyCodeGenerator’:
>> In file included from doxyapp.cpp:31:0:
>> ../../src/outputgen.h:100:18: note: virtual void
>> CodeOutputInterface::writeTooltip(const char*, const DocLinkInfo&, const
>> char*, const char*, const SourceLinkInfo&, const SourceLinkInfo&)
>> doxyapp.cpp:122:19: error: no matching function for call to
>> ‘ParserInterface::parseCode(XRefDummyCodeGenerator&, int, QCString,
>> const bool&, int, FileDef*&)’
>> doxyapp.cpp:122:19: note: candidate is:
>> In file included from doxyapp.cpp:32:0:
>> ../../src/parserintf.h:102:18: note: virtual void
>> ParserInterface::parseCode(CodeOutputInterface&, const char*, const
>> QCString&, SrcLangExt, bool, const char*, FileDef*, int, int, bool,
>> MemberDef*, bool, Definition*)
>> ../../src/parserintf.h:102:18: note: no known conversion for argument 4
>> from ‘const bool’ to ‘SrcLangExt’
>>
>>
>> I don't believe this is an issue with the version of compiler or version
>> of Linux.
> Indeed. The API changed and the doxyapp wasn't updated in the process.
> I've just pushed a fix to GitHub:
> https://github.com/doxygen/doxygen/commit/b07832a11606e3d1b488ee2ab4ec34bb6ccb7921
>
> Regards,
>    Dimitri
>

Re: [Doxygen-users] Current Version DoxyApp Not Building

[Dimitri v. H. <do...@gm...>]

Hi Kevin,

On Sep 11, 2013, at 19:58 , Kevin Nesmith <kne...@si...> wrote:
> I have tried the latest source download, version 1.8.5 and the latest 
> version in git. I have run the configure with the doxyapp parameter. But 
> when the compiler gets to the doxyapp build, I receive the following 
> errors...
> 
> g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools -I../../src 
> -o ../../objects/doxyapp.o doxyapp.cpp
> doxyapp.cpp: In function ‘void findXRefSymbols(FileDef*)’:
> doxyapp.cpp:114:66: error: cannot allocate an object of abstract type 
> ‘XRefDummyCodeGenerator’
> doxyapp.cpp:41:7: note: because the following virtual functions are pure 
> within ‘XRefDummyCodeGenerator’:
> In file included from doxyapp.cpp:31:0:
> ../../src/outputgen.h:100:18: note: virtual void 
> CodeOutputInterface::writeTooltip(const char*, const DocLinkInfo&, const 
> char*, const char*, const SourceLinkInfo&, const SourceLinkInfo&)
> doxyapp.cpp:122:19: error: no matching function for call to 
> ‘ParserInterface::parseCode(XRefDummyCodeGenerator&, int, QCString, 
> const bool&, int, FileDef*&)’
> doxyapp.cpp:122:19: note: candidate is:
> In file included from doxyapp.cpp:32:0:
> ../../src/parserintf.h:102:18: note: virtual void 
> ParserInterface::parseCode(CodeOutputInterface&, const char*, const 
> QCString&, SrcLangExt, bool, const char*, FileDef*, int, int, bool, 
> MemberDef*, bool, Definition*)
> ../../src/parserintf.h:102:18: note: no known conversion for argument 4 
> from ‘const bool’ to ‘SrcLangExt’
> 
> 
> I don't believe this is an issue with the version of compiler or version 
> of Linux.

Indeed. The API changed and the doxyapp wasn't updated in the process.
I've just pushed a fix to GitHub:
https://github.com/doxygen/doxygen/commit/b07832a11606e3d1b488ee2ab4ec34bb6ccb7921

Regards,
  Dimitri

Re: [Doxygen-users] Problem with @copydoc

[Robert D. <rcd...@gm...>]

Sure, bug report submitted:
https://bugzilla.gnome.org/show_bug.cgi?id=707995

Thanks Albert!!

On Thu, Sep 12, 2013 at 1:35 PM, Albert <alb...@gm...> wrote:
> Dear Robert,
>
> With the version 1.8.5 I get these errors as well. With version 1.8.4 all
> looks OK.
> Can you submit a bug report for this problem?
>
> Albert
>
>
>
>
> On Thu, Sep 12, 2013 at 8:16 PM, Robert Dailey <rcd...@gm...>
> wrote:
>>
>> Hey Albert thanks for looking into this. I'm using version 1.8.5 on
>> Windows. I have attached a sample for you, slightly different from
>> what I typed to you earlier. The archive includes
>>
>> - Generated HTML output from doxygen (console_htmldocs folder)
>> - main.cpp, which contains the 'foo' class that needs to be parsed by
>> doxygen.exe
>> - Doxygen configuration file (in the console_htmldocs folder)
>> - An image file that is used as part of my doxygen config
>>
>> The output I get when I run doxygen is:
>>
>> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
>> recursive @copybrief or @copydoc relation for argument 'get()'.
>> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
>> recursive @copybrief or @copydoc relation for argument 'get()'.
>> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
>> recursive @copydetails or @copydoc relation for argument 'get()'.
>>
>> On Thu, Sep 12, 2013 at 11:22 AM, Albert <alb...@gm...> wrote:
>> > Dear Robert,
>> >
>> > I've tried your small program with version 1.8.5 and I don't get the
>> > message, when using version 1.8.4 I get the message:
>> > Warning: recursive call chain of \copydoc commands detected at 8
>> >
>> > Which version do you use?
>> >
>> > Best regards,
>> >
>> > Albert
>> >
>> >
>> > On Thu, Sep 12, 2013 at 4:25 PM, Robert Dailey
>> > <rcd...@gm...>
>> > wrote:
>> >>
>> >> I find difficulty in both automatic link generation *and* @copydoc
>> >> when it comes to 'const' overloaded member methods. Example:
>> >>
>> >> class foo
>> >> {
>> >> public:
>> >>   Object* getObject();
>> >>   Object const* getObject() const;
>> >> };
>> >>
>> >> I have JAVADOC_AUTOBRIEF enabled. My documentation for the class above
>> >> is:
>> >>
>> >> class foo
>> >> {
>> >> public:
>> >>   /// Some brief documentation.
>> >>   /// @return Returns the object.
>> >>   Object* getObject();
>> >>
>> >>   /// @copydoc foo::getObject() const
>> >>   Object const* getObject() const;
>> >> };
>> >>
>> >> The warning I get from Doxygen is:
>> >>
>> >> warning: Found recursive @copybrief or @copydoc relation for argument
>> >> 'foo::getObject()'.
>> >>
>> >> What is the proper way to reference functions overloaded by const?
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> How ServiceNow helps IT people transform IT departments:
>> >> 1. Consolidate legacy IT systems to a single system of record for IT
>> >> 2. Standardize and globalize service processes across IT
>> >> 3. Implement zero-touch automation to replace manual, redundant tasks
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Doxygen-users mailing list
>> >> Dox...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>> >
>> >
>
>

Re: [Doxygen-users] Problem with @copydoc

[Albert <alb...@gm...>]

Dear Robert,

With the version 1.8.5 I get these errors as well. With version 1.8.4 all
looks OK.
Can you submit a bug report for this problem?

Albert



On Thu, Sep 12, 2013 at 8:16 PM, Robert Dailey <rcd...@gm...>wrote:

> Hey Albert thanks for looking into this. I'm using version 1.8.5 on
> Windows. I have attached a sample for you, slightly different from
> what I typed to you earlier. The archive includes
>
> - Generated HTML output from doxygen (console_htmldocs folder)
> - main.cpp, which contains the 'foo' class that needs to be parsed by
> doxygen.exe
> - Doxygen configuration file (in the console_htmldocs folder)
> - An image file that is used as part of my doxygen config
>
> The output I get when I run doxygen is:
>
> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
> recursive @copybrief or @copydoc relation for argument 'get()'.
> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
> recursive @copybrief or @copydoc relation for argument 'get()'.
> 3>C:/Work/rdailey-hp/dpd/console/console.cpp(13): warning: Found
> recursive @copydetails or @copydoc relation for argument 'get()'.
>
> On Thu, Sep 12, 2013 at 11:22 AM, Albert <alb...@gm...> wrote:
> > Dear Robert,
> >
> > I've tried your small program with version 1.8.5 and I don't get the
> > message, when using version 1.8.4 I get the message:
> > Warning: recursive call chain of \copydoc commands detected at 8
> >
> > Which version do you use?
> >
> > Best regards,
> >
> > Albert
> >
> >
> > On Thu, Sep 12, 2013 at 4:25 PM, Robert Dailey <rcd...@gm...
> >
> > wrote:
> >>
> >> I find difficulty in both automatic link generation *and* @copydoc
> >> when it comes to 'const' overloaded member methods. Example:
> >>
> >> class foo
> >> {
> >> public:
> >>   Object* getObject();
> >>   Object const* getObject() const;
> >> };
> >>
> >> I have JAVADOC_AUTOBRIEF enabled. My documentation for the class above
> is:
> >>
> >> class foo
> >> {
> >> public:
> >>   /// Some brief documentation.
> >>   /// @return Returns the object.
> >>   Object* getObject();
> >>
> >>   /// @copydoc foo::getObject() const
> >>   Object const* getObject() const;
> >> };
> >>
> >> The warning I get from Doxygen is:
> >>
> >> warning: Found recursive @copybrief or @copydoc relation for argument
> >> 'foo::getObject()'.
> >>
> >> What is the proper way to reference functions overloaded by const?
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> How ServiceNow helps IT people transform IT departments:
> >> 1. Consolidate legacy IT systems to a single system of record for IT
> >> 2. Standardize and globalize service processes across IT
> >> 3. Implement zero-touch automation to replace manual, redundant tasks
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Doxygen-users mailing list
> >> Dox...@li...
> >> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> >
>

Re: [Doxygen-users] Problem with @copydoc

[Albert <alb...@gm...>]

Dear Robert,

I've tried your small program with version 1.8.5 and I don't get the
message, when using version 1.8.4 I get the message:
Warning: recursive call chain of \copydoc commands detected at 8

Which version do you use?

Best regards,

Albert


On Thu, Sep 12, 2013 at 4:25 PM, Robert Dailey <rcd...@gm...>wrote:

> I find difficulty in both automatic link generation *and* @copydoc
> when it comes to 'const' overloaded member methods. Example:
>
> class foo
> {
> public:
>   Object* getObject();
>   Object const* getObject() const;
> };
>
> I have JAVADOC_AUTOBRIEF enabled. My documentation for the class above is:
>
> class foo
> {
> public:
>   /// Some brief documentation.
>   /// @return Returns the object.
>   Object* getObject();
>
>   /// @copydoc foo::getObject() const
>   Object const* getObject() const;
> };
>
> The warning I get from Doxygen is:
>
> warning: Found recursive @copybrief or @copydoc relation for argument
> 'foo::getObject()'.
>
> What is the proper way to reference functions overloaded by const?
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] Problem with @copydoc

[Robert D. <rcd...@gm...>]

I find difficulty in both automatic link generation *and* @copydoc
when it comes to 'const' overloaded member methods. Example:

class foo
{
public:
  Object* getObject();
  Object const* getObject() const;
};

I have JAVADOC_AUTOBRIEF enabled. My documentation for the class above is:

class foo
{
public:
  /// Some brief documentation.
  /// @return Returns the object.
  Object* getObject();

  /// @copydoc foo::getObject() const
  Object const* getObject() const;
};

The warning I get from Doxygen is:

warning: Found recursive @copybrief or @copydoc relation for argument
'foo::getObject()'.

What is the proper way to reference functions overloaded by const?

[Doxygen-users] Fixing Laptop Bugs

[Arthur S. <asc...@at...>]

I'd like to give the Doxygen crew a friendly hug. I reported two bugs several months ago (vrs. 1.8.3 and 1.8.4) and you have apparently fixed them. In vrs. 1.8.3 the graphic information was (most times) missing from the output on my laptop but not on my desktop. In vrs. 1.8.5 it appears fixed (although I have said that before). In vrs. 1.8.4 there was an infinite loop on my laptop and my desktop in both Win7 native and cygwin, which made the version unusable, the loop is gone. 


So thanks. I can get off of 1.8.3 and use the newest and greatest.

art

[Doxygen-users] Current Version DoxyApp Not Building

[Kevin N. <kne...@si...>]

I have tried the latest source download, version 1.8.5 and the latest 
version in git. I have run the configure with the doxyapp parameter. But 
when the compiler gets to the doxyapp build, I receive the following 
errors...

g++ -c -pipe -D_LARGEFILE_SOURCE -Wall -W -g -I../../qtools -I../../src 
-o ../../objects/doxyapp.o doxyapp.cpp
doxyapp.cpp: In function ‘void findXRefSymbols(FileDef*)’:
doxyapp.cpp:114:66: error: cannot allocate an object of abstract type 
‘XRefDummyCodeGenerator’
doxyapp.cpp:41:7: note: because the following virtual functions are pure 
within ‘XRefDummyCodeGenerator’:
In file included from doxyapp.cpp:31:0:
../../src/outputgen.h:100:18: note: virtual void 
CodeOutputInterface::writeTooltip(const char*, const DocLinkInfo&, const 
char*, const char*, const SourceLinkInfo&, const SourceLinkInfo&)
doxyapp.cpp:122:19: error: no matching function for call to 
‘ParserInterface::parseCode(XRefDummyCodeGenerator&, int, QCString, 
const bool&, int, FileDef*&)’
doxyapp.cpp:122:19: note: candidate is:
In file included from doxyapp.cpp:32:0:
../../src/parserintf.h:102:18: note: virtual void 
ParserInterface::parseCode(CodeOutputInterface&, const char*, const 
QCString&, SrcLangExt, bool, const char*, FileDef*, int, int, bool, 
MemberDef*, bool, Definition*)
../../src/parserintf.h:102:18: note: no known conversion for argument 4 
from ‘const bool’ to ‘SrcLangExt’


I don't believe this is an issue with the version of compiler or version 
of Linux.

Any help would be greatly appreciated.

Kevin Nesmith

[Doxygen-users] [VHDL Package] dependencies documentation

[PEYRON M. <m.p...@se...>]

Hi,

When I call out-of-scope functions/types/constant/etc. from a package or an rtl source, Doxygen do not generate an hyperlink to the called package member in the generated documentation.
I use version 1.8.4.

In the example below, when I look at the generated HTML page documenting the "pack_constant" package, the constant "C_my_constant" is properly documented, but there is no hyperlink on "f_my_fonction" redirecting to the HTML page documenting the "pack_util" package.
In the "pack_util" HTML page, the "f_my_function" is properly documented though.
By the way, when members of a package (resp. rtl source)  are called within the same package (resp. rtl source), hyperlinks are correctly inserted by Doxygen (to somewhere in the same page...)


Example:

===========================================
--! @package pack_util

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.ALL;

--! @brief Package description
--!
package pack_util is
--! Function description
   function f_my_function (valeur : integer) return integer;
end pack_util;

--! body description
package body pack_util is
--! @brief fonction description
function f_my_function (valeur : integer) return integer is
   ...
end function  f_my_function;
end pack_util;

===========================================
--! @package pack_constant

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.ALL;
library work;
use WORK.pack_util.f_my_function;
--! -----------------------------------------------------------------------------------------------------
--! @brief Package description
--!
package pack_constant is
   constant C_my_constant  : integer := f_my_function(123456);--! constant description
end pack_constant;

===========================================



Thanks in advance.

Re: [Doxygen-users] Consecutive \verbatim flaw?; Alternative to //! inside \verbatim?

[Bulgrien, K. <Kev...@GD...>]

> -----Original Message-----
>
> The "box"-ing you see is a side-effect of Markdown support
> (try setting MARKDOWN_SUPPORT=NO)

Excellent.  Thank-you.  That helped.  The documentation now looks like
what I envisioned, and the comment is placed back where I originally
wanted it to go.

Interestingly, \verbatim needed to immediately follow the preceeding
paragraph with no intervening blank lines.  With blank lines between
the preceeding paragraph and the \verbatim command, the verbatim
content seemed to be ignored (missing from the generated
documentation).

---
Kevin R. Bulgrien
New Product Development Engineer

This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

[Doxygen-users] OUTPUT_DIRECTORY not recognised

[aLUNZ <al...@no...>]

I have recently built a new Fedora workstation which is intended to be a
duplicate of other workstations. In our environment Doxygen ouput is sent to
a SAMBA share mounted (using cifs) under '/mnt/docs'. For the other
workstations this configuration works fine. However when I run Doxygen from
the command line I get the following:
----
[dev@localhost prot]$ doxygen
error: tag OUTPUT_DIRECTORY: Output directory `/mnt/docs/prot' does not
exist and cannot be created
Exiting...
[dev@localhost prot]$ 
----

This is despite the fact that the directory does exist (it was in fact built
previously by one of the other workstations) and I can 'ls' it and
create/remove files and/or directories just fine. If I then remove that
directory and re-launch Doxygen things work:
----
[dev@localhost prot]$ rm -rf /mnt/docs/prot
[dev@localhost prot]$ doxygen
Notice: Output directory `/mnt/docs/prot' does not exist. I have created it
for you.
Searching for include files...
Searching for example files...
Searching for images...
    ....
finalizing index lists...
lookup cache used 1696/65536 hits=11814 misses=1732
finished...
[dev@localhost prot]$ 
----

However, if I immediately re-run Doxygen I am back to the 'directory does
not exist' error.  This is a known good Doxygen file (used by other
workstations) and if I set OUTPUT_DIRECTORY to a local directory then things
work. 

I realise that this is almost certainly a problem with permissions or the
cifs mount configuration, however:
 - The configuration is copied from other working workstations
 - Doxygen is the only application (that I am aware of at least) that has a
problem with this (or any mount)

So I am asking for help in identifying what might be going wrong and how can
I fix this.  Is there any way to get Doxygen to report the actual error that
it is having with the output directory?

Sorry for the lengthy post. Any suggestion would be appreciated.

Cheers,
aLUNZ






--
View this message in context: http://doxygen.10944.n7.nabble.com/OUTPUT-DIRECTORY-not-recognised-tp6260.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] INPUT all directoris bellow

[Richard D. <Ri...@Da...>]

On 9/7/13 3:52 PM, Arbol One wrote:
> I was wondering if it would be possible to document all the header
> files with out having to specify ne name of sub-folders.
> Something like this:
> # The INPUT tag can be used to specify the files and/or directories
> that contain
> # documented source files. You may enter file names like "myfile.cpp" or
> # directories like "/usr/src/myproject". Separate the files or directories
> # with spaces.
>  
> INPUT                  = "*.*"

# The RECURSIVE tag can be used to turn specify whether or not subdirectories 
# should be searched for input files as well. Possible values are YES and NO. 
# If left blank NO is used.

RECURSIVE              = YES



-- 
Richard Damon

[Doxygen-users] INPUT all directoris bellow

[Arbol O. <Arb...@ho...>]

I was wondering if it would be possible to document all the header files with out having to specify ne name of sub-folders. 
Something like this:
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.

INPUT                  = "*.*"

Re: [Doxygen-users] Consecutive \verbatim flaw?; Alternative to //! inside \verbatim?

[Dimitri v. H. <do...@gm...>]

Hi Kevin,

@verbatim indeed preserves the //! comments 
(to allow these to appear in the output, I use them in the manual for instance).

The "box"-ing you see is a side-effect of Markdown support (try setting MARKDOWN_SUPPORT=NO)

In general I recommend to use C-style comments for page documentation, i.e.

/*! 
@page Com Windows COM
@section ComRegistry Registry Example

COM depends on registration of COM servers in the Windows Registry...

@verbatim
__uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...

@endverbatim
*/

this doesn't have the issues you encountered.

Regards,
  Dimitri

On Sep 6, 2013, at 23:02 , "Bulgrien, Kevin" <Kev...@GD...> wrote:

> Moving the \page, \section, and \verbatim outside the function body comes
> close to doing what I want BUT any text between @section and @verbatim is
> placed in its own "box" as though it was bounded by \verbatim and
> \endverbatim.
> 
> //! @page Com Windows COM
> //! @section ComRegistry Registry Example
> //!
> //! COM depends on registration of COM servers in the Windows Registry...
> //!
> //! @verbatim
> //! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
> //!
> //! @endverbatim
> 
> To restate, on the Com page, the text beginning "COM depends" appears
> inside a separate, but similar, box that \verbatim ... \endverbatim
> text appears in.  It looks as though styling is being applied to a
> container rather than to a sub-container holding the verbatim text.
> 
> Actually, the generated HTML source says:
> 
> <h1><a class="anchor" id="ComRegistry"></a>
> Registry Example</h1>
> <pre class="fragment">COM depends...
> </pre><pre class="fragment">//! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
> </pre> </div></div><!-- contents -->
> 
> Based on the source HTML of other \page \section text, I would have
> expected more along the lines of:
> 
> <h1><a class="anchor" id="ComRegistry"></a>
> Registry Example</h1>
> <p>COM depends...</p>
> <pre class="fragment">//! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
> </pre> </div></div><!-- contents -->
> 
> It has the appearance that I need to avoid use of \verbatim to avoid
> repercussions in the generated documentation.  There must be a fair
> number of undocumented conditions when use of \verbatim is unwise.
> 
> ---
> Kevin R. Bulgrien
> New Product Development Engineer
> 
> The author is not under control of what appears below this point...
> 
> This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.
> 
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Collaboration diagram does not show private members in 1.8.x

[Yongwei Wu <wuy...@gm...>]

On 6 September 2013 14:28, Petr Prikryl <Pr...@sk...> wrote:
> Yongwei Wu wrote:
>> >> I really like to be able to show all data members in the diagram
>> >> without documenting them....
>> >
>> > Then you should set EXTRACT_PRIVATE to YES.
>>
>> You missed the "without documenting them" part :-).
>>
>> It is arguable that the original behaviour might be better. People
>> normally want to hide the private data members from documentation, but
>> the purpose of the collaboration diagram is to show the relationship
>> between this class and other objects. To put it to the extreme: In a
>> well-designed class, all data members are normally private; does it
>> mean that the collaboration diagram will NOT show anything then?
>
> Well, but does it make sense to generate a documentation without
> documenting anything?

My intention is just show how the class relates to (collaborates with)
other classes. Showing that class A associates with class B is one
thing, but showing that I have a data member called blah of type B in
class A (and requiring people to document it) is another.

> It may be difficult to judge without the real example, but...
>
> If you want to show the implementation internals (like the private
> members), you probably want to tell the programmer
> also what are they good for. If you want to hide the implementation
> (i.e. document only the API), then you also want to hide the internal
> collaboration. (Say, you want to hide it because it is subject
> to changes.)

It makes some sense to me, but, again, there is a subtle difference
between telling people that class A collaborates with class B and
telling people that class A has a data member named blah is of type B.

To give a fake example which is somewhat real, how do you want to document this:

template <class T>
class shared_ptr {
    ...
}

Does it make sense to show that shared_ptr collaborates with T without
documenting all the implementation details about shared_ptr's private
members?

> To summarize, it is natural--in my opinion--not to show the collaboration
> diagram for hidden functionality; or, it is natural to show also
> the documentation for the revealed parts of the collaboration
> graph.
>
> You may consider to generate several versions of the documentation:
> one of the end user, one for third party programmers (API), and
> one for you with the smallest details.

I can see it is not an easy call. Does it make sense to add a new
option for the collaboration diagram, something like
UNDOC_MEMBERS_IN_COLLAB_DIAGRAM or PRIVATE_MEMBERS_IN_COLLAB_DIAGRAM?

Best regards,

Yongwei

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

Re: [Doxygen-users] Consecutive \verbatim flaw?; Alternative to //! inside \verbatim?

[Bulgrien, K. <Kev...@GD...>]

Moving the \page, \section, and \verbatim outside the function body comes
close to doing what I want BUT any text between @section and @verbatim is
placed in its own "box" as though it was bounded by \verbatim and
\endverbatim.

//! @page Com Windows COM
//! @section ComRegistry Registry Example
//!
//! COM depends on registration of COM servers in the Windows Registry...
//!
//! @verbatim
//! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
//!
//! @endverbatim

To restate, on the Com page, the text beginning "COM depends" appears
inside a separate, but similar, box that \verbatim ... \endverbatim
text appears in.  It looks as though styling is being applied to a
container rather than to a sub-container holding the verbatim text.

Actually, the generated HTML source says:

<h1><a class="anchor" id="ComRegistry"></a>
Registry Example</h1>
<pre class="fragment">COM depends...
</pre><pre class="fragment">//! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
</pre> </div></div><!-- contents -->

Based on the source HTML of other \page \section text, I would have
expected more along the lines of:

<h1><a class="anchor" id="ComRegistry"></a>
Registry Example</h1>
<p>COM depends...</p>
<pre class="fragment">//! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}...
</pre> </div></div><!-- contents -->

It has the appearance that I need to avoid use of \verbatim to avoid
repercussions in the generated documentation.  There must be a fair
number of undocumented conditions when use of \verbatim is unwise.

---
Kevin R. Bulgrien
New Product Development Engineer

The author is not under control of what appears below this point...

This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

Re: [Doxygen-users] Consecutive \verbatim flaw?; Alternative to //! inside \verbatim?

[Bulgrien, K. <Kev...@GD...>]

> 1) I have markup inside a class constructor like this:
>
>     //! @page Com Windows COM
>     //! @section ComRegistry Registry Example
>     //!
>     //! @verbatim
>     //! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}
>     //!
>     //!
> [HKEY_CLASSES_ROOT\CLSID\{304CE942-6E39-40D8-943A-B913C40C9CD4}]
>     //! @="HNetCfg.FwMgr"
>     //!
>     //! ...
>     //!
> #ifdef DEBUG
>     StringFromCLSID(__uuidof(INetFwMgr), &uuid_string);
>     _RPTW1(_CRT_WARN, L"INetFwMgr %s\n", uuid_string);
> #endif
>     //! __uuidof(INetFwMgr) == {F7898AF5-CAC4-4632-A2EC-DA06E5111AF2}
>     //!
>     //!
> [HKEY_CLASSES_ROOT\Interface\{F7898AF5-CAC4-4632-A2EC-DA06E511
1AF2}] \n
>     //! @="INetFwMgr"
>     //!
>     //! @endverbatim

Apparently, placing \page and friends in a function body is a big no-no.
I just realized doing that effectively breaks the documentation for the
function.  That's too bad.  Moving that documentation outside of the
function body compromises its value when reading the source file
directly.

I can force the function documentation to occur with \fn, but then it
does not contain cross-reference information like "Definition at line
x of File y", References links, and call Graph (as though it was not
found - even though no warnings are given to that effect).

---
Kevin R. Bulgrien
New Product Development Engineer

The author is not under control of what appears below this point...

This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

[Doxygen-users] Consecutive \verbatim flaw?; Alternative to //! inside \verbatim?

[Bulgrien, K. <Kev...@GD...>]

Doxygen 1.8.5, C++, using @ instead of \ for doxygen Special Commands, and
INTERNAL_DOCS          = YES

1) I have markup inside a class constructor like this:

    //! @page Com Windows COM
    //! @section ComRegistry Registry Example
    //!
    //! @verbatim
    //! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}
    //!
    //! [HKEY_CLASSES_ROOT\CLSID\{304CE942-6E39-40D8-943A-B913C40C9CD4}]
    //! @="HNetCfg.FwMgr"
    //!
    //! ...
    //!
#ifdef DEBUG
    StringFromCLSID(__uuidof(INetFwMgr), &uuid_string);
    _RPTW1(_CRT_WARN, L"INetFwMgr %s\n", uuid_string);
#endif
    //! __uuidof(INetFwMgr) == {F7898AF5-CAC4-4632-A2EC-DA06E5111AF2}
    //!
    //! [HKEY_CLASSES_ROOT\Interface\{F7898AF5-CAC4-4632-A2EC-DA06E5111AF2}] \n
    //! @="INetFwMgr"
    //!
    //! @endverbatim

It renders almost as expected.  Four lines appear that correlate to the #ifdef
whether or not but there are four lines in the middle of the verbatim block...
blank for preprocessor commands and if doxygen sees a #define, then either
blank or non-blank lines.  That's NOT the issue.  It makes sense.

I could just leave the markup above and just deal with the blank lines because
#define DEBUG does not appear in source files (only in the IDE), but I tried to
clean up the markup like this:

    //! @page Com Windows COM
    //! @section ComRegistry Registry Example
    //!
    //! @verbatim
    //! __uuidof(NetFwMgr) == {304CE942-6E39-40D8-943A-B913C40C9CD4}
    //!
    //! [HKEY_CLASSES_ROOT\CLSID\{304CE942-6E39-40D8-943A-B913C40C9CD4}]
    //! @="HNetCfg.FwMgr"
    //!
    //! ...
    //!
    //! @endverbatim
#ifdef DEBUG
    StringFromCLSID(__uuidof(INetFwMgr), &uuid_string);
    _RPTW1(_CRT_WARN, L"INetFwMgr %s\n", uuid_string);
#endif
    //! @verbatim
    //!
    //! __uuidof(INetFwMgr) == {F7898AF5-CAC4-4632-A2EC-DA06E5111AF2}
    //!
    //! [HKEY_CLASSES_ROOT\Interface\{F7898AF5-CAC4-4632-A2EC-DA06E5111AF2}] \n
    //! @="INetFwMgr"
    //!
    //! ...
    //!
    //! @endverbatim

At this point, the second @verbatim block completely disappears.  THAT is the
issue.  While the original markup is a workaround, it seems like this might
be indicative of a flaw.  I wonder why consecutive @verbatim do not work.

2) As an aside, even though I can see that @verbatim means "verbatim", the //!
all appear in the documentation.  I understand that I could use C-style comments
to workaround that, but that leads to inconsistency in the code commenting.
Maybe there is a better way to do all of this.  If so, I could use a hint to
push me in the right direction.

---
Kevin R. Bulgrien
New Product Development Engineer

The author is not under control of what appears below this point...

This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

Re: [Doxygen-users] Collaboration diagram does not show private members in 1.8.x

[Petr P. <Pr...@sk...>]

Yongwei Wu wrote:
> >> I really like to be able to show all data members in the diagram
> >> without documenting them....
> >
> > Then you should set EXTRACT_PRIVATE to YES.
> 
> You missed the "without documenting them" part :-).
> 
> It is arguable that the original behaviour might be better. People
> normally want to hide the private data members from documentation, but
> the purpose of the collaboration diagram is to show the relationship
> between this class and other objects. To put it to the extreme: In a
> well-designed class, all data members are normally private; does it
> mean that the collaboration diagram will NOT show anything then?

Well, but does it make sense to generate a documentation without
documenting anything?

It may be difficult to judge without the real example, but...

If you want to show the implementation internals (like the private 
members), you probably want to tell the programmer
also what are they good for. If you want to hide the implementation
(i.e. document only the API), then you also want to hide the internal
collaboration. (Say, you want to hide it because it is subject 
to changes.)

To summarize, it is natural--in my opinion--not to show the collaboration
diagram for hidden functionality; or, it is natural to show also
the documentation for the revealed parts of the collaboration 
graph.

You may consider to generate several versions of the documentation:
one of the end user, one for third party programmers (API), and
one for you with the smallest details.

Regards, 
    Petr

Re: [Doxygen-users] Collaboration diagram does not show private members in 1.8.x

[Yongwei Wu <wuy...@gm...>]

On 5 September 2013 23:33, Dimitri van Heesch <do...@gm...> wrote:
>
> On Sep 5, 2013, at 15:59 , Yongwei Wu <wuy...@gm...> wrote:
>
>> In Doxygen 1.6.x and earlier, the collaboration diagram will show all
>> members regardless its visibility. I have found that 1.8.x does not
>> show the private members, unless EXTRACT_PRIVATE is set to YES. Is
>> this an intentional change?
>
> Yes that has changed since version 1.7.5, based on bug reports.
>
>> I really like to be able to show all data members in the diagram
>> without documenting them....
>
> Then you should set EXTRACT_PRIVATE to YES.

You missed the "without documenting them" part :-).

It is arguable that the original behaviour might be better. People
normally want to hide the private data members from documentation, but
the purpose of the collaboration diagram is to show the relationship
between this class and other objects. To put it to the extreme: In a
well-designed class, all data members are normally private; does it
mean that the collaboration diagram will NOT show anything then?

So I am asking to revisit this decision.

Best regards,

Yongwei

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

Re: [Doxygen-users] Collaboration diagram does not show private members in 1.8.x

[Dimitri v. H. <do...@gm...>]

On Sep 5, 2013, at 15:59 , Yongwei Wu <wuy...@gm...> wrote:

> In Doxygen 1.6.x and earlier, the collaboration diagram will show all
> members regardless its visibility. I have found that 1.8.x does not
> show the private members, unless EXTRACT_PRIVATE is set to YES. Is
> this an intentional change?

Yes that has changed since version 1.7.5, based on bug reports.

> I really like to be able to show all data members in the diagram
> without documenting them....

Then you should set EXTRACT_PRIVATE to YES.

Regards,
  Dimitri