doxygen-users — List for users of doxygen

Re: [Doxygen-users] Another question....

[woody <kn...@re...>]

At 09:00 AM 9/4/2015 +0100, Frank Peelo wrote:
>If you're really going to have different parameter names, the ones in the 
>header should be the ones documented. The documentation is for people who 
>are going to use the function;

Precisely, that is why it should be the FUNCTION ACTUAL HEADER

>the people working on the function body can read the code. People using 
>the function can see the .h file, which has the prototype,

Nope.  In this case the prototype is in the C code.  The target audience 
for this documentation is management.
HOWEVER: In this case, what they will see is not the C code, but a detailed 
verbal english description of the code. (My boss refuses
to learn any C code, yet he wants a detailed spec specifying what the 
program is doing in English.)
The html however, will allow direct access to the body of the file, and 
when it says that

for function foo the input parameters are   int offtime    and offtime is 
not used or referenced in the code, then that is a problem.
The "references" section of the html header lists all references used in 
the module.  When it says  off    and there is no   off in the
code, nor in the header, that sends you off on a tangent trying to find 
where in the hell  off  is in the code.
So the parameter list that is in the documentation for the specific 
function, SHOULD match the function, or it leads to confusion.

The disconnect is that it uses the prototype and states that those 
parameters are used in the function, when indeed, there may not be ANY 
values with that name.

Consider this:

foo (int, int,int,char);      // a prototype with no identifiers, which is 
quite legal

foo (int time, int off, int on, char flag)

The current way of doing it would result in

foo
       int
       int
       int

Which does not help with understanding the function.  In this case it should be

foo
     int time
     int off
     int on
     char flag


so doxygen SHOULD use the actual name in the function, not the prototype, 
because the prototype can be written with NOT NAME AT ALL for the parameters.

>and may not have access to the .c code; if they do have that, they 
>shouldn't need to read it. So Doxygen *should* use the names in the 
>prototype, instead of the ones in the .c file.
>
>Frank
>
>On 03/09/15 21:16, woody wrote:
>>It seems that Doxygen uses the prototype definition when it creates 
>>documentation for a function in the html and rtf files.
>>
>>For example,
>>
>>The actual definition of initiate_beep
>>static void initiate_beep (int duration,int off, char count)
>>{
>>// code body
>>}
>>
>>the prototype:
>>static void initiate_beep (int duration,int offtime,char count);
>>
>>
>>The compiler is just fine with this, because all it cares about is the 
>>type.  However, doxygen picks up the prototype, and uses that as the 
>>header for the html and in the rtf file,
>>and puts only the body of the code under the header, showing the 
>>prototype as the parameters, which of course can cause problems in 
>>understanding and documenting code if the programmer
>>used different names for the same type.
>>
>>of course in the body of the code, it is just   off    so *really* 
>>doxygen SHOULD be using the actual function definition, if there is one.
>>that is, if there is a function that matches the prototype as far as 
>>variable types, then the definition line where the function is actually 
>>found, should be used to
>>show the calling parameters, not the prototype.
>>
>>This is easy to check.  Just create a function and a prototype, use 
>>different names for the same type parameters, and run through doxygen.
>>
>>Doxygen should document code *as written*  or in construction terms "as 
>>built" rather than "as planned".
>>prototypes are "as planned" items, actual functions are "as written".
>>
>>And YES, before anyone says anything else, IT IS BAD PRACTICE to use 
>>variable names that are different between function and prototype....
>>
>>
>>
>>
>>------------------------------------------------------------------------------
>>Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>>Get real-time metrics from all of your servers, apps and tools
>>in one place.
>>SourceForge users - Click here to start your Free Trial of Datadog now!
>><http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140>http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>>
>>
>>_______________________________________________
>>Doxygen-users mailing list
>><mailto:Dox...@li...>Dox...@li...
>>https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>------------------------------------------------------------------------------
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Another question....

[Frank P. <f2...@ei...>]

If you're really going to have different parameter names, the ones in 
the header should be the ones documented. The documentation is for 
people who are going to use the function; the people working on the 
function body can read the code. People using the function can see the 
.h file, which has the prototype, and may not have access to the .c 
code; if they do have that, they shouldn't need to read it. So Doxygen 
*should* use the names in the prototype, instead of the ones in the .c 
file.

Frank

On 03/09/15 21:16, woody wrote:
> It seems that Doxygen uses the prototype definition when it creates 
> documentation for a function in the html and rtf files.
>
> For example,
>
> The actual definition of initiate_beep
> static void initiate_beep (int duration,int off, char count)
> {
> // code body
> }
>
> the prototype:
> static void initiate_beep (int duration,int offtime,char count);
>
>
> The compiler is just fine with this, because all it cares about is the 
> type.  However, doxygen picks up the */prototype/*, and uses that as 
> the header for the html and in the rtf file,
> and puts only */the body/* of the code under the header, showing the 
> *prototype *as the parameters, which of course can cause problems in 
> understanding and documenting code if the programmer
> used different names for the same type.
>
> of course in the body of the code, it is just off    so *really* 
> doxygen SHOULD be using the actual function definition, if there is one.
> that is, if there is a function that matches the prototype as far as 
> variable types, then the definition line where the function is 
> actually found, should be used to
> show the calling parameters, not the prototype.
>
> This is easy to check.  Just create a function and a prototype, use 
> different names for the same type parameters, and run through doxygen.
>
> Doxygen should document code *as written*  or in construction terms 
> "as built" rather than "as planned".
> prototypes are "as planned" items, actual functions are "as written".
>
> And YES, before anyone says anything else, IT IS BAD PRACTICE to use 
> variable names that are different between function and prototype....
>
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Another question....

[woody <kn...@re...>]

It seems that Doxygen uses the prototype definition when it creates 
documentation for a function in the html and rtf files.

For example,

The actual definition of initiate_beep
static void initiate_beep (int duration,int off, char count)
{
// code body
}

the prototype:
static void initiate_beep (int duration,int offtime,char count);


The compiler is just fine with this, because all it cares about is the 
type.  However, doxygen picks up the prototype, and uses that as the header 
for the html and in the rtf file,
and puts only the body of the code under the header, showing the prototype 
as the parameters, which of course can cause problems in understanding and 
documenting code if the programmer
used different names for the same type.

of course in the body of the code, it is just   off    so *really* doxygen 
SHOULD be using the actual function definition, if there is one.
that is, if there is a function that matches the prototype as far as 
variable types, then the definition line where the function is actually 
found, should be used to
show the calling parameters, not the prototype.

This is easy to check.  Just create a function and a prototype, use 
different names for the same type parameters, and run through doxygen.

Doxygen should document code *as written*  or in construction terms "as 
built" rather than "as planned".
prototypes are "as planned" items, actual functions are "as written".

And YES, before anyone says anything else, IT IS BAD PRACTICE to use 
variable names that are different between function and prototype....

Re: [Doxygen-users] Hide "Class Hierachy" page?

[Gopal P. <Gop...@In...>]

Hi All,

Please tell me how can I add a docx file in Doxygen and make it readable by clicking on document.

Regards,
Gopal

From: Albert [mailto:alb...@gm...]
Sent: Wednesday, September 02, 2015 1:22 PM
To: Zack Snyder
Cc: dox...@li...
Subject: Re: [Doxygen-users] Hide "Class Hierachy" page?

Zack,
Please have a look at DoxygenLayout.xml(generated by doxygen -w) and look here for "classes"
Alebrt

On Tue, Sep 1, 2015 at 8:45 PM, Zack Snyder <za...@gm...<mailto:za...@gm...>> wrote:
Hi all,

how can I hide the "Class Hierachy" page?

Regards,
Zack

------------------------------------------------------------------------------
_______________________________________________
Doxygen-users mailing list
Dox...@li...<mailto:Dox...@li...>
https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Hide "Class Hierachy" page?

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

Zack,

Please have a look at DoxygenLayout.xml(generated by doxygen -w) and look
here for "classes"

Alebrt

On Tue, Sep 1, 2015 at 8:45 PM, Zack Snyder <za...@gm...> wrote:

> Hi all,
>
> how can I hide the "Class Hierachy" page?
>
> Regards,
> Zack
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Re: [Doxygen-users] Doxygen-warnings

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

Sai,

1) Looks like you have  a bit of a big dependency graph, like the message
said increase the DOT_GRAPH_MAX_NODES (in the Doxyfile) and also have  a
look at MAX_DOT_GRAPH_DEPTH.
Are there more graphs that fail ?

Regarding points 2 and 3 I'm not sure but might be a result of 1). I assume
dot has been installed properly.

Albert





On Wed, Sep 2, 2015 at 7:55 AM, sai mrithyunjaya <ts...@gm...> wrote:

> Hi All,
>
> We are trying to run *.c and .h* files through doxygen(1.8.10) and got
> the below warnings:
>
>
> 1)      warning: Caller graph for
> 'com.trwautomotive.das.rhapsody.apps.SkeletonCodeGeneratorChild.process'
> not generated, too many nodes. Consider increasing DOT_GRAPH_MAX_NODES.
>
> 2)      error: Problems running dot: exit code=-1, command='dot',
> arguments='"
> D:/doc/html/classcom_1_config_a328df2e18418091d70d01df1ad27f64c_cgraph.dot"
> -Tpng -o
>
> "D: /doc/html/classcom_1
> _config_a328df2e18418091d70d01df1ad27f64c_cgraph.png"'
>
> 3)      error: problems opening map file D:/
> doc/html/classcom_1_scan_code__coll__graph.map
>
> for inclusion in the docs!
>
> If you installed Graphviz/dot after a previous failing run,
>
> try deleting the output directory and rerun doxygen.
>
>
>
> Could anyone please help us to fix these warnings.
>
>
>
>
>
> Thank you
> Sai
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Doxygen-warnings

[sai m. <ts...@gm...>]

Hi All,

We are trying to run *.c and .h* files through doxygen(1.8.10) and got the
below warnings:


1)      warning: Caller graph for
'com.trwautomotive.das.rhapsody.apps.SkeletonCodeGeneratorChild.process'
not generated, too many nodes. Consider increasing DOT_GRAPH_MAX_NODES.

2)      error: Problems running dot: exit code=-1, command='dot',
arguments='"
D:/doc/html/classcom_1_config_a328df2e18418091d70d01df1ad27f64c_cgraph.dot"
-Tpng -o

"D: /doc/html/classcom_1
_config_a328df2e18418091d70d01df1ad27f64c_cgraph.png"'

3)      error: problems opening map file D:/
doc/html/classcom_1_scan_code__coll__graph.map

for inclusion in the docs!

If you installed Graphviz/dot after a previous failing run,

try deleting the output directory and rerun doxygen.



Could anyone please help us to fix these warnings.





Thank you
Sai

[Doxygen-users] Hide "Class Hierachy" page?

[Zack S. <za...@gm...>]

Hi all,

how can I hide the "Class Hierachy" page?

Regards,
Zack

Re: [Doxygen-users] another rtf example, why is this happening.

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

Does this problem also occur with other output formats (HTML, LaTeX / pdf)?
Please create a small program with Doxyfile so we can see what happens in
the different output formats

Albert

On Mon, Aug 31, 2015 at 10:00 PM, woody <kn...@re...> wrote:

>
> *::Some more items that are missing *From the .rtf file
>
> These routines are interrupt handlers, and the last routine is code to
> write a byte of data to the flash on a Silabs 8051 processor.
> You will notice that the line     "References, and . " Don't have anything
> listed..  in the first case it should be
>
> "References bttn1_debounce and bcount" OR  since this is an embedded
> project, EX0 is defined in a file that was not processed, but represents a
> specific bit in a specific register,
> so it should also be included, even though it is not listed anywhere other
> than within the body of this code, it should be picked up because of that.
> It is not a local
> it is a global, but doxygen does not have knowledge of it.
> but it *is* referenced within the function.....
>
> References:
> bttn1_debounce
> EX0
> bcount
>
>
>
>
> *void button_scan_interrupt_1 () *Definition at line 5719 of file xxx.
> References , and .
>  5720     {
>  5721     EX0=0;// disable any further interrupts from this pin to let
> bouncing settle
>  5722     bttn1_debounce=20;                 // 20 miliseconds
>  5723     bcount=0;                          // start the 2 x per second
> counter at 0
>  5724     }
>
>
> *::void button_scan_interrupt_2 () *Definition at line 5734 of file xxx.
> References , and .
>  5735     {
>  5736     EX1=0;// disable any further intterupts from this pin to let
> bouncing settle
>  5737     bttn2_debounce=20;                 // 20 miliseconds
>  5738     bcount=0;                          //
>  5739     }
>
>
>
>
>
>
> *::char erase_flash (unsigned char *  page_address)
> <<<<<<<<<<<<<<<<<<<<<<<<?????????????????  This got listed but without
> anything else. ::void FLASH_ByteWrite (unsigned int  addr, char  byte) *Definition
> at line 8420 of file xxx.
> References .
> Referenced by , and .
>  8421 {
>  8422     saved_ie=IE;
>  8423     EA = 0;                    // disable interrupts
>  8424     PSCTL = 0x00;              // MOVX writes target XRAM to keep
> interrupt from happening
>  8425     EA=0;
>  8426     RSTSRC = 0x02;                   // enable VDD monitor as a
> reset source
>  8427     FLKEY = 0xa5;              // 1st FLASH key sequence
>  8428     FLKEY = 0xf1;              // 2nd FLASH key sequence
>  8429     PSCTL = 0x01;              // MOVX writes target FLASH memory
>  8430     ((unsigned char volatile xdata *) 0)[addr]=byte;
>  8431     PSCTL = 0x00;              // MOVX writes target XRAM
>  8432     IE=saved_ie;
>  8433 }
>
> Again, saved_ie is a global, so not sure why it got missed.
>
> This function is called by  configure_me, which is in turn called from
> main.
> It is also called by main in a different place,
>
> The caller graph which could not be pasted here, shows
> main calling configure_me and configure_me calling FLASH_ByteWrite, AND it
> shows a line from main directly to FLASH_ByteWrite, so the caller graph is
> correct.
>
>
> Based on this, the lines should look like:
>
>
> *void FLASH_ByteWrite (unsigned int  addr, char  byte) *Definition at
> line 8420 of file medbest_310_o_split.c.
> References saved_ie
> Referenced by configure_me  and main.
>
> Why is this happening
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] another rtf example, why is this happening.

[woody <kn...@re...>]

::Some more items that are missing
 From the .rtf file

These routines are interrupt handlers, and the last routine is code to 
write a byte of data to the flash on a Silabs 8051 processor.
You will notice that the line     "References, and . " Don't have anything 
listed..  in the first case it should be

"References bttn1_debounce and bcount" OR  since this is an embedded 
project, EX0 is defined in a file that was not processed, but represents a 
specific bit in a specific register,
so it should also be included, even though it is not listed anywhere other 
than within the body of this code, it should be picked up because of that.
It is not a local
it is a global, but doxygen does not have knowledge of it.
but it *is* referenced within the function.....

References:
bttn1_debounce
EX0
bcount


void button_scan_interrupt_1 ()

Definition at line 5719 of file xxx.
References , and .
  5720     {
  5721     EX0=0;// disable any further interrupts from this pin to let 
bouncing settle
  5722     bttn1_debounce=20;                 // 20 miliseconds
  5723     bcount=0;                          // start the 2 x per second 
counter at 0
  5724     }
::void button_scan_interrupt_2 ()

Definition at line 5734 of file xxx.
References , and .
  5735     {
  5736     EX1=0;// disable any further intterupts from this pin to let 
bouncing settle
  5737     bttn2_debounce=20;                 // 20 miliseconds
  5738     bcount=0;                          //
  5739     }


::char erase_flash (unsigned char *  page_address) 
<<<<<<<<<<<<<<<<<<<<<<<<?????????????????  This got listed but without 
anything else.

::void FLASH_ByteWrite (unsigned int  addr, char  byte)

Definition at line 8420 of file xxx.
References .
Referenced by , and .
  8421 {
  8422     saved_ie=IE;
  8423     EA = 0;                    // disable interrupts
  8424     PSCTL = 0x00;              // MOVX writes target XRAM to keep 
interrupt from happening
  8425     EA=0;
  8426     RSTSRC = 0x02;                   // enable VDD monitor as a 
reset source
  8427     FLKEY = 0xa5;              // 1st FLASH key sequence
  8428     FLKEY = 0xf1;              // 2nd FLASH key sequence
  8429     PSCTL = 0x01;              // MOVX writes target FLASH memory
  8430     ((unsigned char volatile xdata *) 0)[addr]=byte;
  8431     PSCTL = 0x00;              // MOVX writes target XRAM
  8432     IE=saved_ie;
  8433 }

Again, saved_ie is a global, so not sure why it got missed.

This function is called by  configure_me, which is in turn called from main.
It is also called by main in a different place,

The caller graph which could not be pasted here, shows
main calling configure_me and configure_me calling FLASH_ByteWrite, AND it 
shows a line from main directly to FLASH_ByteWrite, so the caller graph is 
correct.


Based on this, the lines should look like:
void FLASH_ByteWrite (unsigned int  addr, char  byte)

Definition at line 8420 of file medbest_310_o_split.c.
References saved_ie
Referenced by configure_me  and main.

Why is this happening

Re: [Doxygen-users] Small question to a "strange" line in output file dynsections.js

[Schleusener, J. <Jen...@t-...>]

Hi Dimitri,

> I think I found the problem. Resource::data was used directly as a string, but it is not \0 terminated!
> I've just pushed the following change to address this, which also makes the ResourceMgr::get() method private
> so it cannot be (ab)used like this anymore.
>
> https://github.com/doxygen/doxygen/commit/15a87a623791bf407b3076960cdd1133c8973357

Thanks, that patch respectively the latest development version of doxygen 
lets the "strange" line vanish.

And for completeness: I use doxygen under Linux (not Windows) and as 
Albert mentioned with SOURCE_BROWSER and SOURCE_TOOLTIPS set to YES.

Regards,

Jens

>> On 31 Aug 2015, at 19:01 , Albert <alb...@gm...> wrote:
>>
>> Jens,
>>
>> I tried to reproduce the problem (on windows) with the current head and was not successful.
>> The htmlgen.cpp had no changes related to dynsections.js in the relevant part (mentioned lines 731 - 756) in the mentioned period and the template dynsections.js has never been changed since its introduction in that directory (November 13, 2014).
>>
>> By default the dynsections.js is 97 lines long and when setting SOURCE_BROWSER and SOURCE_TOOLTIPS to YES the code is extended by the lines specified in htmlgen.cpp. These lines are just "pasted" and don't contain special characters.
>>
>> Albert
>>
>> On Mon, Aug 31, 2015 at 5:22 PM, Schleusener, Jens <Jen...@t-...> wrote:
>> Hi,
>>
>> since 2th June 2015 appears in the output file dynsections.js a new line
>> that appears at least to me as layman a little bit strange.
>>
>> The output file dynsections.js seems to be primarly contain the static
>> contents of the file ./doxygen/templates/html/dynsections.js maybe
>> complemented by the JavaScript code generated by the lines 731-756 of
>> doxygen/src/htmlgen.cpp.
>>
>> Just between this both code segments there is now at line 98 (at least in
>> my applications of the current development version of Doxygen) a line
>> containing the hex code 440C (ASCII: D + Formfeed).
>>
>> Is that the expected behaviour or possibly a small error?
>>
>> Sorry for the a little bit unprofessional problem description.
>>
>> Regards
>>
>> Jens
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Re: [Doxygen-users] Small question to a "strange" line in output file dynsections.js

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

Hi Jens & Albert,

I think I found the problem. Resource::data was used directly as a string, but it is not \0 terminated!
I've just pushed the following change to address this, which also makes the ResourceMgr::get() method private 
so it cannot be (ab)used like this anymore.

https://github.com/doxygen/doxygen/commit/15a87a623791bf407b3076960cdd1133c8973357

Regards,
  Dimitri

> On 31 Aug 2015, at 19:01 , Albert <alb...@gm...> wrote:
> 
> Jens,
> 
> I tried to reproduce the problem (on windows) with the current head and was not successful.
> The htmlgen.cpp had no changes related to dynsections.js in the relevant part (mentioned lines 731 - 756) in the mentioned period and the template dynsections.js has never been changed since its introduction in that directory (November 13, 2014).
> 
> By default the dynsections.js is 97 lines long and when setting SOURCE_BROWSER and SOURCE_TOOLTIPS to YES the code is extended by the lines specified in htmlgen.cpp. These lines are just "pasted" and don't contain special characters.
> 
> Albert
> 
> On Mon, Aug 31, 2015 at 5:22 PM, Schleusener, Jens <Jen...@t-...> wrote:
> Hi,
> 
> since 2th June 2015 appears in the output file dynsections.js a new line
> that appears at least to me as layman a little bit strange.
> 
> The output file dynsections.js seems to be primarly contain the static
> contents of the file ./doxygen/templates/html/dynsections.js maybe
> complemented by the JavaScript code generated by the lines 731-756 of
> doxygen/src/htmlgen.cpp.
> 
> Just between this both code segments there is now at line 98 (at least in
> my applications of the current development version of Doxygen) a line
> containing the hex code 440C (ASCII: D + Formfeed).
> 
> Is that the expected behaviour or possibly a small error?
> 
> Sorry for the a little bit unprofessional problem description.
> 
> Regards
> 
> Jens
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Small question to a "strange" line in output file dynsections.js

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

Jens,

I tried to reproduce the problem (on windows) with the current head and was
not successful.
The htmlgen.cpp had no changes related to dynsections.js in the relevant
part (mentioned lines 731 - 756) in the mentioned period and the template
dynsections.js has never been changed since its introduction in that
directory (November 13, 2014).

By default the dynsections.js is 97 lines long and when setting
SOURCE_BROWSER and SOURCE_TOOLTIPS to YES the code is extended by the lines
specified in htmlgen.cpp. These lines are just "pasted" and don't contain
special characters.

Albert

On Mon, Aug 31, 2015 at 5:22 PM, Schleusener, Jens <
Jen...@t-...> wrote:

> Hi,
>
> since 2th June 2015 appears in the output file dynsections.js a new line
> that appears at least to me as layman a little bit strange.
>
> The output file dynsections.js seems to be primarly contain the static
> contents of the file ./doxygen/templates/html/dynsections.js maybe
> complemented by the JavaScript code generated by the lines 731-756 of
> doxygen/src/htmlgen.cpp.
>
> Just between this both code segments there is now at line 98 (at least in
> my applications of the current development version of Doxygen) a line
> containing the hex code 440C (ASCII: D + Formfeed).
>
> Is that the expected behaviour or possibly a small error?
>
> Sorry for the a little bit unprofessional problem description.
>
> Regards
>
> Jens
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Re: [Doxygen-users] FILE_PATTERNS: one custom plus all defaults

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

Dear Clayton,

The pull request 383 has been integrated in the main branch.

Albert

On Mon, Aug 24, 2015 at 11:11 AM, Clayton <cla...@gm...> wrote:

> Hi Albert, I just built your pull request
>
>         https://github.com/doxygen/doxygen/pull/383
>
> from source and tested it on a hundred+ github javascript repositories,
> it works as expected: lots of javascript output. We would really like to
> see this patch merged into master.
>
> Plus, the current master quite likely gives many people the impression
> that doxygen processing of javascript is broken, which it is not.
>
> Thanks for writing the fix,
> Clayton
>
> On Mon, 17 Aug 2015 18:44:48 +0200
> Albert <alb...@gm...> wrote:
>
> > Bug report is not really needed.
> >
> > I don't think the other places are in conflict.
> > There is no separate javascript parser but it is more or less
> > integrated in the c parser. The g_lang2extMap tells that javascript
> > type of files have to be parsed by the c parser and that the type of
> > language is SrcLangExt_JS. With the later it is possible to ask in
> > the code which language a file has and do special things for this
> > language.
> >
> > The initDefaultExtensionMapping maps the files extension to the
> > language type of files.
> >
> > Albert
> >
> >
> >
> >
> > On Mon, Aug 17, 2015 at 10:09 AM, Clayton <cla...@gm...> wrote:
> >
> > > Thanks for the quick work, Albert. Does this mean a bug report is
> > > now no longer needed? (That's quite the list of bugs in
> > > Bugzilla....)
> > >
> > > It looks to me like your patch leaves js in. And I am in fact
> > > seeing at least two different references in util.cpp, which also
> > > might be in conflict:
> > >
> > > g_lang2extMap[] =
> > > {
> > > //  language       parser           parser option
> > >   { "javascript",  "c",             SrcLangExt_JS       },
> > >
> > >
> > > void initDefaultExtensionMapping()
> > > {
> > >   g_extLookup.setAutoDelete(TRUE);
> > >   //                  extension      parser id
> > >   updateLanguageMapping(".as",       "javascript");
> > >   updateLanguageMapping(".js",       "javascript");
> > >
> > > The second reference above gives the impression that there is an
> > > internal doxygen parser for javascript? Really??
> > >
> > > Clayton
> > >
> > >
> > >
> > >
> > > On Sun, 16 Aug 2015 18:21:46 +0200
> > > Albert <alb...@gm...> wrote:
> > >
> > > > I've just pushed a proposed patch to github (pull request 383)
> > > >
> > > > Albert
> > > >
> > > > On Sun, Aug 16, 2015 at 4:06 PM, Albert <alb...@gm...>
> > > > wrote:
> > > >
> > > > > The following does not yet solve your problem, but points in the
> > > > > direction where we have to look to solve the problem:
> > > > > There is in util.cpp another list which does contain .js, looks
> > > > > like a small inconsistency between config.xml, util.cpp and
> > > > > config.l. Please file a bug report to signal this discrepancy.
> > > > >
> > > > > Albert
> > > > >
> > > > >
> > > > > On Sun, Aug 16, 2015 at 3:09 PM, Clayton <cla...@gm...>
> > > > > wrote:
> > > > >
> > > > >> On Sun, 16 Aug 2015 14:05:56 +0200
> > > > >> Stefan Pendl <ste...@gm...> wrote:
> > > > >>
> > > > >> > Am 16.08.2015 um 13:45 schrieb Clayton:
> > > > >> > > Hi doxygen,
> > > > >> > >
> > > > >> > > I am looking at the config file and writing to ask if I am
> > > > >> > > missing something.
> > > > >> > >
> > > > >> > > I am using
> > > > >> > >
> > > > >> > >     FILE_PATTERNS = *.js
> > > > >> > >     FILTER_PATTERNS = *.js=plugins/js2doxy/js2doxy.pl
> > > > >> >
> > > > >> > From the help file topic "Configuration => Configuration
> > > > >> > options related to the input files => FILE_PATTERNS" it
> > > > >> > seems that *.js is included in the default already.
> > > > >> >
> > > > >> > Is your doxygen version less than v1.8.10?
> > > > >>
> > > > >> Hi Stefan, the help is not the same as the code, from
> > > > >> src/config.l in a very recent clone of the source, I believe
> > > > >> this to be the ACTUAL default list of file patterns:
> > > > >>
> > > > >>   QStrList &filePatternList = Config_getList("FILE_PATTERNS");
> > > > >>   if (filePatternList.isEmpty())
> > > > >>   {
> > > > >>     filePatternList.append("*.c");
> > > > >>     filePatternList.append("*.cc");
> > > > >>     filePatternList.append("*.cxx");
> > > > >>     filePatternList.append("*.cpp");
> > > > >>     filePatternList.append("*.c++");
> > > > >>     filePatternList.append("*.java");
> > > > >>     filePatternList.append("*.ii");
> > > > >>     filePatternList.append("*.ixx");
> > > > >>     filePatternList.append("*.ipp");
> > > > >>     filePatternList.append("*.i++");
> > > > >>     filePatternList.append("*.inl");
> > > > >>     filePatternList.append("*.h");
> > > > >>     filePatternList.append("*.hh");
> > > > >>     filePatternList.append("*.hxx");
> > > > >>     filePatternList.append("*.hpp");
> > > > >>     filePatternList.append("*.h++");
> > > > >>     filePatternList.append("*.idl");
> > > > >>     filePatternList.append("*.odl");
> > > > >>     filePatternList.append("*.cs");
> > > > >>     filePatternList.append("*.php");
> > > > >>     filePatternList.append("*.php3");
> > > > >>     filePatternList.append("*.inc");
> > > > >>     filePatternList.append("*.m");
> > > > >>     filePatternList.append("*.mm");
> > > > >>     filePatternList.append("*.dox");
> > > > >>     filePatternList.append("*.py");
> > > > >>     filePatternList.append("*.f90");
> > > > >>     filePatternList.append("*.f");
> > > > >>     filePatternList.append("*.for");
> > > > >>     filePatternList.append("*.vhd");
> > > > >>     filePatternList.append("*.vhdl");
> > > > >>     filePatternList.append("*.tcl");
> > > > >>     filePatternList.append("*.md");
> > > > >>     filePatternList.append("*.markdown");
> > > > >>
> > > > >> *.js is not in there. The plugin is necessary, the point is,
> > > > >> how to get the plugin to integrate with the default list
> > > > >> automatically, without explicitly adding the default list to
> > > > >> FILE_PATTERNS.
> > > > >>
> > > > >> Thanks,
> > > > >> Clayton
> > > > >>
> > > > >>
> > > > >>
> > >
> ------------------------------------------------------------------------------
> > > > >> _______________________________________________
> > > > >> Doxygen-users mailing list
> > > > >> Dox...@li...
> > > > >> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> > > > >>
> > > > >
> > > > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Doxygen-users mailing list
> > > Dox...@li...
> > > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> > >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] Small question to a "strange" line in output file dynsections.js

[Schleusener, J. <Jen...@t-...>]

Hi,

since 2th June 2015 appears in the output file dynsections.js a new line 
that appears at least to me as layman a little bit strange.

The output file dynsections.js seems to be primarly contain the static 
contents of the file ./doxygen/templates/html/dynsections.js maybe 
complemented by the JavaScript code generated by the lines 731-756 of 
doxygen/src/htmlgen.cpp.

Just between this both code segments there is now at line 98 (at least in 
my applications of the current development version of Doxygen) a line 
containing the hex code 440C (ASCII: D + Formfeed).

Is that the expected behaviour or possibly a small error?

Sorry for the a little bit unprofessional problem description.

Regards

Jens

Re: [Doxygen-users] Doxygen Ignores Some Files in Specified Folder

[Ousia <pet...@ho...>]

Well, so, I tried it again and double-checked all permissions. I made sure
everyone had full access to all files but the problem still persists.

Does someone have another idea?



--
View this message in context: http://doxygen.10944.n7.nabble.com/Doxygen-Ignores-Some-Files-in-Specified-Folder-tp7349p7356.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Two strange things about Doxygen and my code

[Bostjan M. <cco...@gm...>]

On Sun, Aug 30, 2015 at 12:54 AM, Christoph Lipka
<chr...@li...> wrote:
> Am 26.08.2015 um 15:16 schrieb Bostjan Mihoric:
>
> On Wed, Aug 26, 2015 at 2:41 PM, Christoph Lipka
> <chr...@li...> wrote:
>
> Am 26.08.2015 um 11:14 schrieb Bostjan Mihoric:
>
> On Tue, Aug 25, 2015 at 7:14 PM, Christoph Lipka
> <chr...@li...> wrote:
>
> Am 25.08.2015 um 18:36 schrieb Bostjan Mihoric:
> [...]
>
> /// @file
>
> /// My typedef.
> typedef void VOID;
>
> /// My simple function. Details.
> extern VOID Function(VOID);
> [...]
>
> [...]
>
> Yes, I agree that anything but "void" should be considered a different
> type. What I meant is, why doesn't it work when I try to use Doxygen's
> preprocessor to redefine "VOID" back  to "void". Surely it doesn't
> preprocess *after* deciding if function has a return value /
> parameters? If it's preprocessor replaced "VOID" with "void", why
> doesn't it then see it as "void"?
>
>
> Did you set "MACRO_EXPANSION = YES"? The default value of "No" causes
> Doxygen's preprocessor to only do conditional compilation.
>

Yes, resolved by this. Thank you!

Re: [Doxygen-users] Two strange things about Doxygen and my code

[Christoph L. <chr...@li...>]

Am 26.08.2015 um 15:16 schrieb Bostjan Mihoric:
> On Wed, Aug 26, 2015 at 2:41 PM, Christoph Lipka
> <chr...@li...> wrote:
>> Am 26.08.2015 um 11:14 schrieb Bostjan Mihoric:
>>> On Tue, Aug 25, 2015 at 7:14 PM, Christoph Lipka
>>> <chr...@li...> wrote:
>>>> Am 25.08.2015 um 18:36 schrieb Bostjan Mihoric:
>>>> [...]
>>>>
>>>> /// @file
>>>>
>>>> /// My typedef.
>>>> typedef void VOID;
>>>>
>>>> /// My simple function. Details.
>>>> extern VOID Function(VOID);
>>>> [...]
[...]
> Yes, I agree that anything but "void" should be considered a different
> type. What I meant is, why doesn't it work when I try to use Doxygen's
> preprocessor to redefine "VOID" back  to "void". Surely it doesn't
> preprocess *after* deciding if function has a return value /
> parameters? If it's preprocessor replaced "VOID" with "void", why
> doesn't it then see it as "void"?

Did you set "MACRO_EXPANSION = YES"? The default value of "No" causes
Doxygen's preprocessor to only do conditional compilation.

Re: [Doxygen-users] why does it doxygen miss functions?

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

On 8/28/15 4:58 PM, woody wrote:
> I ran doxygen 1.8.10 with default settings on a file that had no 
> doxygen comments in it.
>
> Something is seriously wrong here, what is going on?
> *EVERY SINGLE FUNCTION* tagged static was skipped.
See option: EXTRACT_STATIC (default is NO),

This option must be set to YES to include the documentation for static 
items.

-- 
Richard Damon

[Doxygen-users] why does it doxygen miss functions?

[woody <kn...@re...>]

I ran doxygen 1.8.10 with default settings on a file that had no doxygen 
comments in it.

Below is my list of prototypes, just as they are in the C code.  Each 
function is present in the C code.
Some of them are only *called* from within conditional code blocks 
i.e.   if then else code.
The lines highlighted in BOLD were not included in the .rtf file, and when 
you go to the HTML code you have
main Page, Data Structures and   Files.  With no functions listed anywhere.
Clicking on files, brings up tabs  File List        Globals
Again, no functions.  Looking at the output directory there is 
a  functions.html file, when opened has nothing showing in the body,  just 
the fields of the various
data structures.
Something is seriously wrong here, what is going on?
EVERY SINGLE FUNCTION tagged static was skipped.
Those were tagged static to make sure the compiler did not screw 
up     keil 7.5 for the 8051.


void power_down();
void button_scan_interrupt_1();
void timer_0_interrupt ();             // interrupt 1 using 3
void button_scan_interrupt_2();        // interrupt 2 using 1
void timer_1_interrupt ();             // interrupt 3 using 3
char erase_flash(unsigned char * page_address);
static void zero_average_values();// zeros the pulse wdith buffers, running 
averages etc when you change modes.
void uart_0_interrupt();               // interrupt 4 using 0
void timer_2_interrupt ();             // interrupt 5 using 3
void spi_interrupt() ;                 //interrupt 6 using 0
void SMB_interrupt ();                 // interrupt 7 using 0
void USB_interrupt();                  // interrupt 8 using 0
void adc_window_interrupt();           // interrupt 9 using 1
void adc_window_complete();            // interrupt 10 using 1
void PCA_interrupt_handler();          // interrupt 11 using 2
void comparator_0_interrupt();         // interrupt 12 using 0
void comparator_1_interrupt();         // interrupt 13 using 0
void timer_3_interrupt ();             // interrupt 14 using 3
void VBUS_interrupt();                 // interrupt 15 using 0
//
// Note: while not strictly necessary, supplying the return type lets the 
compiler produce tighter code because the optimizer does not have
// to preserve registers etc.
// by addint the      static   modifier to the function, the compiler can 
also produce tighter code because on the 8051 there are
// two types of jumps and calls,  some types (ACALL) vs LCALL take 
differing times and byte sizes.  Same for jumps and SJMP.there
// a call and sjump instructions operate in a limited address range, (2k 
and 256 bytes), so by letting the compiler know what kind of
// function it is, (since static functions are know only in the module in 
which they are defined) the compiler knows that it does not have
// to worry about the linker having to generate  addresses for these, and 
it can then rearrange them  and/or knows that they are within
// range of a short jump or call.  It can thus generate the mose effecient 
call or jump as needed, since it has absolute knowlege at compile time
// of the distance between a function and any caller of that function.
//
//

static void initialize_chip (void) ;
static unsigned char scan_buttons();
static void initialize_internal_timers();
static unsigned char test_x_ram();
void set_led_blink(unsigned int,unsigned int,unsigned int,unsigned int);// 
mask, pattern, time
static void initiate_beep(int duration,int offtime,char count);
static void intergroup_control(struct table * table_pointer,char flags);
static void interpulse_control(struct table * table_pointer,char flags);
static void damping_control(struct table * table_pointer,char flags);
static void intensity_control (struct table *table_pointer,char flag);
static void pulse_control(struct table * table_pointer,char flag);

static void  process_treatment_table(struct treatment_table *treatment,char 
flags);
static void build_array(struct common_header code * table_pointer,char flags);
static void update_current_values(unsigned char flags);
static void update_damping(char next_entry,unsigned char flags);
static void update_pulses(char next_entry,unsigned char flags);
static void update_intensity(char next_entry,unsigned char flags);
static void update_intergroup(char next_entry,unsigned char flags);
static void update_interpulse(char next_entry,unsigned char flags);

void write_flash(unsigned char * destination, unsigned char 
code*  source,   int len);
void FLASH_ByteWrite (unsigned int addr, char byte);
void configure_me();
extern int   rand ();
extern void  srand (int);
void mod_int_incr();
static void check_doseage();

extern void display_intensity(unsigned char intensity);
extern void display_update();
void set_mode_leds(unsigned char flag);
void set_threshold();
extern void body_display();
extern void blue_set_mode();  // this has to be present as a dummy routine 
in all devices to satisfy the linker.
extern void light_leds(int,char);
static void clean_damping_port();

Re: [Doxygen-users] Doxygen Ignores Some Files in Specified Folder

[Ousia <pet...@ho...>]

Hey Albert,

that was quite a quick answer, thanks.

I also thought it might be because of permissions. So I checked them and
changed them on those files but it didn't make any difference. As far as I
am seeing it I don't get any Error Message, too.

I am using Windows 7.

I'll check again about the permissions, though, maybe I was just blind....



--
View this message in context: http://doxygen.10944.n7.nabble.com/Doxygen-Ignores-Some-Files-in-Specified-Folder-tp7349p7351.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Doxygen Ignores Some Files in Specified Folder

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

Sounds a bit like a permission problem, I see sometimes the same when using
vi from cygwin a chmod 755 on the file helps in that case
Which OS are you using?

Albert

On Fri, Aug 28, 2015 at 9:31 AM, Ousia <pet...@ho...> wrote:

> Hello!
>
> I am using Doxygen for a C# Project and it is working quite nicely.
> There is just one issue. I do not know if maybe I am doing something wrong
> :(
>
> When I set up Doxygen to document all files in a Folder it generates the
> output I expected but when I then open a file in that folder, close it
> again
> and run Doxygen again it seems to ignore that file and only document all
> the
> other files.
> So I just started to explicitely tell doxygen the files to document (even
> that seems to not work always, though I don't know when or why not). As the
> project is getting bigger and the files I need to be documented might
> change
> sometime, this is getting quite a lot of work.
>
> Am I forgetting about something?
>
> Thanks a ton for helping!
>
>
>
>
> --
> View this message in context:
> http://doxygen.10944.n7.nabble.com/Doxygen-Ignores-Some-Files-in-Specified-Folder-tp7349.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
>

[Doxygen-users] Doxygen Ignores Some Files in Specified Folder

[Ousia <pet...@ho...>]

Hello!

I am using Doxygen for a C# Project and it is working quite nicely.
There is just one issue. I do not know if maybe I am doing something wrong
:(

When I set up Doxygen to document all files in a Folder it generates the
output I expected but when I then open a file in that folder, close it again
and run Doxygen again it seems to ignore that file and only document all the
other files.
So I just started to explicitely tell doxygen the files to document (even
that seems to not work always, though I don't know when or why not). As the
project is getting bigger and the files I need to be documented might change
sometime, this is getting quite a lot of work.

Am I forgetting about something?

Thanks a ton for helping!




--
View this message in context: http://doxygen.10944.n7.nabble.com/Doxygen-Ignores-Some-Files-in-Specified-Folder-tp7349.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] erroneous output of section label for \cond command

[Monique S. <mon...@ea...>]

>>
>> Is there perhaps some configuration setting that I need to set to 
>> suppress this unexpected output?

>No, did you perhaps add the label also to the \endcond command?

Yes, you're right. I included the label in the \endcond command; don't know 
why. So now the output is all fine.

Thank very much!

-Monique

Re: [Doxygen-users] erroneous output of section label for \cond command

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

Hi Monique,

> On 27 Aug 2015, at 18:43 , Monique Semp <mon...@ea...> wrote:
> 
> Hello, doxygen-users,
>  
> I’m using Doxygen 1.8.10, on Mac 10.10.3 (Yosemite).
>  
> I’ve used the \cond and \endcond tags to omit documentation for some class members, via a section label of the sort __INCLUDE_DOXYGEN_FOR_THESE_DEFINES__. (And of course, I’m not defining these labels in the ENABLED_SECTIONS part of the Doxyfile.)
>  
> The output correctly omits the members that are between the \cond and \endcond commands, but... the section label itself (“__INCLUDE_DOXYGEN_FOR_THESE_DEFINES__”) is appearing in the output, in bold on its own line, in the detailed output for the next documented member in the file. This erroneous output appears before the text of the \details command.
>  
> Is there perhaps some configuration setting that I need to set to suppress this unexpected output?

No, did you perhaps add the label also to the \endcond command? 
If not, then please show a more complete example.

Regards,
  Dimitri