doxygen-users — List for users of doxygen

Re: [Doxygen-users] ?? for page numbers in the indices

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

Does the loop run till the end or does it terminate before the final count is
reached. In the first case what happens if you increase the count?
If the above does not help can you be a bit more precise in where the
problem occurs or better create a small example showing the problem and post
this.



--
View this message in context: http://doxygen.10944.n7.nabble.com/for-page-numbers-in-the-indices-tp6895p6897.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Python import as

[Sebastian H. <seb...@bl...>]

Hi!

I have a python project where modules are imported using 'import as', like

import this.really.long.module.name as trlm

Is there a way to make doxygen understand that subsequent calls to 
something like

trlm.method(...)

is actually a call into this.really.long.module.name.method(...) ?

Cheers,
Sebastian H

Re: [Doxygen-users] How to prevent warning: Unsupported xml/html tag <myTagName> found ?

[dougkramer <dou...@gm...>]

Is there any way to completely turn off the interpretation of <tags> in doc
comments?
We don't use this feature, and would prefer not to litter the comments with
backslashes.



--
View this message in context: http://doxygen.10944.n7.nabble.com/How-to-prevent-warning-Unsupported-xml-html-tag-myTagName-found-tp138p6893.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] doxygen confused with double comment

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

Perry,

Which version are you using? as the current version supplies some extra
information about this problem.
It is also a construct that according to the standard is not allowed.
See also the release notes of version 1.8.7: Add warning when encountering
a nested comment start (/*) without matching end (*/).

Albert

On Wed, Nov 5, 2014 at 8:03 PM, Perry Smith <pe...@gm...> wrote:

> I just discovered that Doxygen gets confused with:
>
>             /* printf("J");     /* debug */
>
> HTH
> Perry
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] doxygen confused with double comment

[Perry S. <pe...@gm...>]

I just discovered that Doxygen gets confused with:

	    /* printf("J");	/* debug */

HTH
Perry

[Doxygen-users] Relationship between Fortran classes in different modules

[Ronan V. <ron...@ec...>]

Hi,

I am using version 1.8.8. With the simple code below, doxygen is not able to relate correctly type_B as a child of type_A as soon as both are declared in different modules.

type_A and type_B are referred as A::type_A and B::type_B respectively in the generated documentation. B::Type_B is set as a child of an unknown class Type_A, not the one whose definition is imported from the module.

Is there a way to fix this ?

Using “!> @extends A::type_A “ forces the correct relationship but does not remove the erroneous one. This create a documentation for Type_B with two parents Type_A and A::Type_A.

Thanks,
Ronan


!—————————————————————————————————————
!—————————————————————————————————————
module A
implicit none

!> @brief Parent class
type :: type_A
  integer :: i
  contains
    procedure :: set_i
end type

contains

subroutine set_i(this, val)
class(type_A) :: this
integer :: val
this%i = val
end subroutine set_i

end module A

module B
use A, only : type_A
implicit none

!> @brief Child class in separate module
type, extends(type_A) :: type_B
  integer :: j
  contains
    procedure :: set_j
end type

contains

subroutine set_j(this, val)
class(type_B) :: this
integer :: val
this%j = val
end subroutine set_j

end module B

Re: [Doxygen-users] input buffer overflow, can't enlarge buffer because scanner uses REJECT

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

Please see the FAQ of the manual how to handle.



--
View this message in context: http://doxygen.10944.n7.nabble.com/input-buffer-overflow-can-t-enlarge-buffer-because-scanner-uses-REJECT-tp6885p6888.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] How do I hide #included files from showing up?

[Egor T. <ego...@gm...>]

Oh, nevermind, just found the "SHOW_INCLUDE_FILES" option.

On Sun, Nov 2, 2014 at 1:03 AM, Egor Tensin <ego...@gm...> wrote:
> Hello,
>
> Could please someone tell me if I can easily hide #included files from
> showing up at the top of documentation generated for *.cpp files?
> Those are not of particular relevance for my code.
>
> Thanks,
> Egor.

[Doxygen-users] How do I hide #included files from showing up?

[Egor T. <ego...@gm...>]

Hello,

Could please someone tell me if I can easily hide #included files from
showing up at the top of documentation generated for *.cpp files?
Those are not of particular relevance for my code.

Thanks,
Egor.

Re: [Doxygen-users] Importing Doxygen Output into Word

[starfuryAll <mar...@al...>]

Hi Ken,

In reply to  this
<http://doxygen.10944.n7.nabble.com/Importing-Doxygen-Output-into-Word-tp6881.html>  
and your other post " RTF Tags Not Resolved
<http://doxygen.10944.n7.nabble.com/RTF-Tags-Not-Resolved-tp6880.html>  ".

Ken Kazinski wrote
> [...] I have a large word document.  I would like to import a Doxygen
> output into my document as an appendix.  When I export to a RTF all the
> styles are wrong. [...]
> Is there a easy way to get the styles out of word and into Doxygen or a
> easy way to import my refman.xxx file?
> [...]

The RTF-Output of Doxygen is not very well maintained, and I read somewhere
that it was already considered to remove it at all. Luckily this has not yet
happened.

But following steps worked for me. Not perfect but sufficient:
1. Open generated "refmain.rtf"
2. Select all the content of the document ([Ctrl]+[A]) and press [F9] to
update all the field functions (fixes "RTF Tags Not Resolved")
3. Search and replace all section breaks (search for "^b") in the generated
parts (replace with nothing "").
4. Copy the required parts of the generated document to your other Word
document (paste as "RTF formatted text")
(actually I did 4 before 3, but it makes more sense this way, doesn't it?)

This way all the styles of your original document should be applied to the
generated content as well.

HTH, Markus




--
View this message in context: http://doxygen.10944.n7.nabble.com/Importing-Doxygen-Output-into-Word-tp6881p6882.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] [1.8.8] Using PlantUML (startuml/enduml) block causes subsequent customized ALIASES tags to be unusable

[James A. <ang...@gm...>]

Hello Dimitri,

Although, the latest GIT windows binaries (doxygenw20140924_1_8_8.zip
2014-09-24) does not include that necessary patch for PlantUML, it
reported an error

"..\src\plantuml.cpp<61>: Internal error: Requested unknown option
PLANTUML_INCLUDE_PATH!" when running the 64-bit version.

I'm hoping that you can upload at least a GIT windows binaries that
can do a proper PlantUML test soon.

Thks alot in adv.

Regards,
James.


On Wed, Oct 29, 2014 at 9:02 AM, JamesAng <ang...@gm...> wrote:
> Hello Dimitri,
>
> Thanks for the quick response.
>
> When is the next planned binaries release for Windows?
>
> Regards,
> James
>
>
>
> --
> View this message in context: http://doxygen.10944.n7.nabble.com/1-8-8-Using-PlantUML-startuml-enduml-block-causes-subsequent-customized-ALIASES-tags-to-be-unusable-tp6874p6877.html
> Sent from the Doxygen - Users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users



-- 
Regards,
James

[Doxygen-users] Importing Doxygen Output into Word

[Ken K. <kjk...@ya...>]

 I have searched the lists but I have not found anything that meets my needs.
I have a large word document.  I would like to import a Doxygen output into my document as an appendix.  When I export to a RTF all the styles are wrong.  I have looked at the information on the RTF style sheet and one of the posts suggested pointing Doxygen to the normal.dot (normal.dotm) file.  I tried that but Doxygen gave me a number of errors.
Is there a easy way to get the styles out of word and into Doxygen or a easy way to import my refman.xxx file?
Thanks.

[Doxygen-users] RTF Tags Not Resolved

[Ken K. <kjk...@ya...>]

I created a RTF output but when I opened the refman.rtf none of the tags are resolved (i.e. pagenum).  Is there a post process step I am missing to have all the tags resolved?
Thanks.





  

[Doxygen-users] Empty "referenced by" for some functions

[Vincent L. <vin...@in...>]

Hello,

I'm surprised to find out that some of the functions in the C++ project I'm working on have an empty "referenced by" list despite the fact they are called. 

Let's call f one of the functions with empty "referenced by". And let's call g a function that calls f. I see that g lists f in its "references" list. How come g is not in f's "referenced by" list? Am I misunderstanding something?

I must add that f and g are actually template functions. And that f is overloaded. Is it a known limitation of Doxygen to forget about these functions in the "referenced by" and "caller graph"?

The detailed real examples that I have is with foo an overloaded version of f. foo has the empty referenced by. Whereas f has a big referenced by list that I suspect contains the foo's callers.

I use Doxygen 1.8.8 with doxywizard.

(FWIW, my initial intent was to spot useless functions, ones that were never called.)

Thank you in advance,
anyway, Doxygen is a great tool!

Vincent Liard

[Doxygen-users] Is it possible to remove a nav item without corresponding tree item being removed?

[didje <dia...@pd...>]

I would like to remove certain of the top navigation links, but preserve
those links in the tree index on the left hand side of the generated
documentation. Is this possible? 

In the DoxygenLayout.xml file, there is no way to do this - once I change a
nav item, setting visible to "no", the item is removed both from the top
navigation links and the left hand side column menu.

I am also interested in doing this the other way around - i.e. removing a
link from the left hand side column but preserving it in the top navigation
links.

Is this simply impossible or is there a workaround to do it?




--
View this message in context: http://doxygen.10944.n7.nabble.com/Is-it-possible-to-remove-a-nav-item-without-corresponding-tree-item-being-removed-tp6878.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] [1.8.8] Using PlantUML (startuml/enduml) block causes subsequent customized ALIASES tags to be unusable

[JamesAng <ang...@gm...>]

Hello Dimitri,

Thanks for the quick response.

When is the next planned binaries release for Windows?

Regards,
James



--
View this message in context: http://doxygen.10944.n7.nabble.com/1-8-8-Using-PlantUML-startuml-enduml-block-causes-subsequent-customized-ALIASES-tags-to-be-unusable-tp6874p6877.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] [1.8.8] Using PlantUML (startuml/enduml) block causes subsequent customized ALIASES tags to be unusable

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

Hi James,

This seems to be fixed in GitHub already, most likely by this fix:
https://github.com/doxygen/doxygen/commit/4df52916170bb81179697d0fa78c7d81fd95415f

Regards,
  Dimitri

> On 28 Oct 2014, at 3:52 , James Ang <ang...@gm...> wrote:
> 
> Sorry, re-send if you cannot see the detailed section as Nabble scrubbed it.
> 
> ----
> 
> In 1.8.8,
> using PlantUML (v8009) (startuml/enduml) block causes subsequent customized
> ALIASES tags to be unusable.
> 
> Config:
> 
> ALIASES += t="&nbsp; &nbsp; &nbsp;"
> ALIASES += sup{1}="<SUP>\1</SUP>"
> ALIASES += sub{1}="<SUB>\1</SUB>"
> ALIASES += b{1}="<B>\1</B>"
> ALIASES += i{1}="<I>\1</I>"
> 
> 
> C file:
> 
> /*! customized aliases bug.
> 
>  The first \sup{alias} tab \t\[here\] is \b{\i{working}} before the
> \sub{start} of startuml.
> 
>  \startuml
>  Alice -> Bob: Authentication Request
>  Bob --> Alice: Authentication Response
>  Alice -> Bob: Another authentication Request
>  Alice <-- Bob: another authentication Response
>  \enduml
> 
>  Another \i{alias} tab after enduml \t\[here\] is \sub{not} working \b{with} a
>  \sup{warning}: "Found unknown command" or "expected whitespace after"
> 
>  All customised aliases are gone.
> */
> 
> 
> log file:
> 
> test.c:12: warning: Found unknown command `\i'
> test.c:12: warning: Found unknown command `\t'
> test.c:12: warning: Found unknown command `\sub'
> test.c:12: warning: expected whitespace after { command
> test.c:13: warning: Found unknown command `\sup'
> test.c:3: warning: Found unknown command `\t'
> 
> 
> On Tue, Oct 28, 2014 at 10:38 AM, JamesAng <ang...@gm...> wrote:
>> In 1.8.8,
>> using PlantUML (v8009) (startuml/enduml) block causes subsequent customized
>> ALIASES tags to be unusable.
>> 
>> Config:
>> 
>> 
>> C file:
>> 
>> 
>> log file:
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context: http://doxygen.10944.n7.nabble.com/1-8-8-Using-PlantUML-startuml-enduml-block-causes-subsequent-customized-ALIASES-tags-to-be-unusable-tp6874.html
>> Sent from the Doxygen - Users mailing list archive at Nabble.com.
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 
> 
> 
> -- 
> Regards,
> James
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] [1.8.8] Using PlantUML (startuml/enduml) block causes subsequent customized ALIASES tags to be unusable

[James A. <ang...@gm...>]

Sorry, re-send if you cannot see the detailed section as Nabble scrubbed it.

----

In 1.8.8,
using PlantUML (v8009) (startuml/enduml) block causes subsequent customized
ALIASES tags to be unusable.

Config:

ALIASES += t="     "
ALIASES += sup{1}="<SUP>\1</SUP>"
ALIASES += sub{1}="<SUB>\1</SUB>"
ALIASES += b{1}="<B>\1</B>"
ALIASES += i{1}="<I>\1</I>"


C file:

/*! customized aliases bug.

  The first \sup{alias} tab \t\[here\] is \b{\i{working}} before the
\sub{start} of startuml.

  \startuml
  Alice -> Bob: Authentication Request
  Bob --> Alice: Authentication Response
  Alice -> Bob: Another authentication Request
  Alice <-- Bob: another authentication Response
  \enduml

  Another \i{alias} tab after enduml \t\[here\] is \sub{not} working \b{with} a
  \sup{warning}: "Found unknown command" or "expected whitespace after"

  All customised aliases are gone.
 */


log file:

test.c:12: warning: Found unknown command `\i'
test.c:12: warning: Found unknown command `\t'
test.c:12: warning: Found unknown command `\sub'
test.c:12: warning: expected whitespace after { command
test.c:13: warning: Found unknown command `\sup'
test.c:3: warning: Found unknown command `\t'


On Tue, Oct 28, 2014 at 10:38 AM, JamesAng <ang...@gm...> wrote:
> In 1.8.8,
> using PlantUML (v8009) (startuml/enduml) block causes subsequent customized
> ALIASES tags to be unusable.
>
> Config:
>
>
> C file:
>
>
> log file:
>
>
>
>
>
> --
> View this message in context: http://doxygen.10944.n7.nabble.com/1-8-8-Using-PlantUML-startuml-enduml-block-causes-subsequent-customized-ALIASES-tags-to-be-unusable-tp6874.html
> Sent from the Doxygen - Users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users



-- 
Regards,
James

[Doxygen-users] [1.8.8] Using PlantUML (startuml/enduml) block causes subsequent customized ALIASES tags to be unusable

[JamesAng <ang...@gm...>]

In 1.8.8,
using PlantUML (v8009) (startuml/enduml) block causes subsequent customized
ALIASES tags to be unusable.

Config:


C file:


log file:





--
View this message in context: http://doxygen.10944.n7.nabble.com/1-8-8-Using-PlantUML-startuml-enduml-block-causes-subsequent-customized-ALIASES-tags-to-be-unusable-tp6874.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Identifying Objective-C code from the XML

[Michael J. <m.p...@gm...>]

Hi,

Thank you for the quick response. I'm glad you think the project is
interesting and I am very grateful for the links you provide to Breathe
from your documentation.

It is good to know Doxygen stores the language for the definitions. For
Breathe, it certainly would be useful to have the source language in the
XML output as it seems the code needs to make similar rendering decisions
as your HTML output code does. I'm not sure how best to represent it or at
what level to have it specified. I imagine you have a good feel for that.
Being inexperienced at Objective-C I get confused, but I guess the ability
to mix Objective-C and plain C style declarations means it would have to go
on each definition rather than any higher up.

If you think it is acceptable for the XML output then great, if you can see
a better approach then I'd be happy to learn. Thanks again.

Kind regards,
Michael


On Sun, Oct 26, 2014 at 11:54 AM, Dimitri van Heesch <do...@gm...>
wrote:

> Hi Michael,
>
> > On 26 Oct 2014, at 12:15 , Michael Jones <m.p...@gm...> wrote:
> >
> > I am the maintainer of an open source project called Breathe which
> relies on the excellent xml output from Doxygen to include Doxygen
> processed code & comment information in Sphinx documentation.
>
> A very interesting project!
>
> > Breathe has generally focussed on C & C++ output but recently we've had
> requests to support Objective-C code as well which has very different
> formatting. As Breathe doesn't know any better it attempts to stick the
> information in the XML together as if it is C style output and so produces
> a bit of a mess for Objective-C style declarations.
> >
> > I am curious how doxygen tracks that a particular declaration should be
> output as Objective-C and how that might be reflected in the XML output in
> such as way that Breathe might take advantage of it.
> >
> > Unfortunately, I know very little of Objective-C so I don't really know
> what I am looking for. That said, from an inspection of the XML output for
> an example Objective-C interface the only clues I can see are that the
> 'ids' begin with 'interface' and that there are strangely placed square
> brackets and colons in the definition & param values :)
> >
> > Is the 'interface' prefix sufficient information in this case? Is there
> another way of determining that Objective-C might be involved?
>
> Doxygen internally keeps track of which language a symbol is written in
> (see Definition::getLanguage()).
> This information is partly based on the file extension (and
> EXTENSION_MAPPING setting) and is for Objective-C also based on specific
> keywords found in the header file.
>
> So far this information is not written to the XML output, but it would not
> be hard to add this if that would help you.
>
> Regards,
>   Dimitri
>
>

Re: [Doxygen-users] Identifying Objective-C code from the XML

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

Hi Michael,

> On 26 Oct 2014, at 12:15 , Michael Jones <m.p...@gm...> wrote:
> 
> I am the maintainer of an open source project called Breathe which relies on the excellent xml output from Doxygen to include Doxygen processed code & comment information in Sphinx documentation.

A very interesting project!

> Breathe has generally focussed on C & C++ output but recently we've had requests to support Objective-C code as well which has very different formatting. As Breathe doesn't know any better it attempts to stick the information in the XML together as if it is C style output and so produces a bit of a mess for Objective-C style declarations.
> 
> I am curious how doxygen tracks that a particular declaration should be output as Objective-C and how that might be reflected in the XML output in such as way that Breathe might take advantage of it.
> 
> Unfortunately, I know very little of Objective-C so I don't really know what I am looking for. That said, from an inspection of the XML output for an example Objective-C interface the only clues I can see are that the 'ids' begin with 'interface' and that there are strangely placed square brackets and colons in the definition & param values :)
> 
> Is the 'interface' prefix sufficient information in this case? Is there another way of determining that Objective-C might be involved?

Doxygen internally keeps track of which language a symbol is written in (see Definition::getLanguage()).
This information is partly based on the file extension (and EXTENSION_MAPPING setting) and is for Objective-C also based on specific keywords found in the header file.

So far this information is not written to the XML output, but it would not be hard to add this if that would help you.

Regards,
  Dimitri

[Doxygen-users] Fwd: Identifying Objective-C code from the XML

[Michael J. <m.p...@gm...>]

Hi,

I am the maintainer of an open source project called Breathe which relies
on the excellent xml output from Doxygen to include Doxygen processed code
& comment information in Sphinx documentation.

Breathe has generally focussed on C & C++ output but recently we've had
requests to support Objective-C code as well which has very different
formatting. As Breathe doesn't know any better it attempts to stick the
information in the XML together as if it is C style output and so produces
a bit of a mess for Objective-C style declarations.

I am curious how doxygen tracks that a particular declaration should be
output as Objective-C and how that might be reflected in the XML output in
such as way that Breathe might take advantage of it.

Unfortunately, I know very little of Objective-C so I don't really know
what I am looking for. That said, from an inspection of the XML output for
an example Objective-C interface the only clues I can see are that the
'ids' begin with 'interface' and that there are strangely placed square
brackets and colons in the definition & param values :)

Is the 'interface' prefix sufficient information in this case? Is there
another way of determining that Objective-C might be involved?

Any help would be greatly appreciated,
Michael


ps. I sent this before but without subscribing to the list so I suspect it
was held in a queue. I attempted to cancel it upon sending this but my
token had expired.

[Doxygen-users] can doxyGen produce only code source pages?!

[vladi s. <vla...@gm...>]

hello, i would like to produce only pages with colored src code and surf
the code only by clicking on code variables and jumping directly to other
code pages , kind of what u get by using eclipse and F3 (but at the
browser)... can it be done by some configs of the doxyFile? thanks a lot...

Re: [Doxygen-users] mainpage content not included in index.html

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

Hi Ruth,

The behaviour what doxygen does with files with an unknown (or missing) extension
has recently changed. In the past the files were parsed as C code, now they
are just parsed as plain text.

You can put the following in the configuration file to get the old behaviour.

EXTENSION_MAPPING = no_extension=C

Note there is still a small issue if the file path in which the README is found
contains a dot, then the matching will not work. I'll push a fix for this soon.

Regards,
  Dimitri

> On 24 Oct 2014, at 15:17 , Poole, Ruth J. <Poo...@ma...> wrote:
> 
> I recently installed Doxygen 1.8.8 on a new computer and my \mainpage text
> is no longer working.  I have a file with content like:
> 
> /*!
> 
> \mainpage Title
> 
> Blah blah blah, lots of content...
> 
> */
> 
> 
> On previous Doxygen release 1.6.1, which I have installed on another
> machine, the main page content is included in the index.html.  I have made
> no changes to my Doxygen config file or the file containing the \mainpage
> tag, but it no longer gets included in the index.html with Doxygen 1.8.8.
> 
> Additional info:
> The main page text is in a file called README in the top-level directory.
> My Doxyfile has the file name pattern README in the input list:
> INPUT = .
> FILE_PATTERNS = *.hpp *.h *.hh *.cpp *.cc *.idl README *.sh *.R *.txt
> 
> 
> Ruth
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] mainpage content not included in index.html

[Poole, R. J. <Poo...@ma...>]

I recently installed Doxygen 1.8.8 on a new computer and my \mainpage text
is no longer working.  I have a file with content like:

/*!

\mainpage Title

Blah blah blah, lots of content...

*/


On previous Doxygen release 1.6.1, which I have installed on another
machine, the main page content is included in the index.html.  I have made
no changes to my Doxygen config file or the file containing the \mainpage
tag, but it no longer gets included in the index.html with Doxygen 1.8.8.

Additional info:
The main page text is in a file called README in the top-level directory.
My Doxyfile has the file name pattern README in the input list:
INPUT = .
FILE_PATTERNS = *.hpp *.h *.hh *.cpp *.cc *.idl README *.sh *.R *.txt


Ruth