doxygen-develop — List for discussing new features, submitting patches, etc.

Re: [Doxygen-develop] Spell checking

[Chris C. <do...@ke...>]

On Wed, Jun 22, 2005 at 02:31:11PM +0100, Michael McTernan wrote:

> I was thinking that it would be simple to make a DocVisitor that together
> with something like GNU aspell, could check all the observable text and
> produce warnings for misspelt words.

What's a misspelt (or misspelled) word in a program?  I must have
thousands, just in comments where I refer to variables and functions,
hardware, and things in external specifications.

> Particularly this would be better than extracting the comments from the
> source, and then running a spell checker as things like \a words or \code
> blocks could automatically be skipped.

That would cut down on some, but by no means all.

> Anyone have any comments on this?  If I made such a DocVisitor, would it be
> welcomed?

It sounds like a useful thing if it is optional and doesn't add even
more to the bulk.

Chris C

Re: [Doxygen-develop] Spell checking

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

On 6/22/05, Michael McTernan <Mic...@tt...> wrote:
> Hi there,
>=20
> I'm starting to build up a bit of documentation using Doxygen, and realis=
e
> that I've made the odd spelling mistake.  It would help me if Doxygen wou=
ld
> check spellings while generating documentations and produce warnings.
>=20
> Checking the lists archives, I haven't found anything significant about
> spell checking in Doxygen.  Surely this has been considered before?
>=20
> I was thinking that it would be simple to make a DocVisitor that together
> with something like GNU aspell, could check all the observable text and
> produce warnings for misspelt words.
>=20
> Particularly this would be better than extracting the comments from the
> source, and then running a spell checker as things like \a words or \code
> blocks could automatically be skipped.
>=20
> Anyone have any comments on this?  If I made such a DocVisitor, would it =
be
> welcomed?

I like the idea of using the DocVisitor class in combination with a
user-specified
external tool. So please go ahead and implement this.=20

I think it would require two new string-type config options, i.e
something like:
SPELL_CHECKER_CMD  - command to execute, empty =3D> no spell checking
SPELL_CHECKER_LOG   - log file to write the results to.

The only issue I see is reporting proper line numbers/context info
along with the misspelt words.

Regards,
  Dimitri

Re: [Doxygen-develop] Spell checking

[Duane E. <dua...@fr...>]

> Anyone have any comments on this?  If I made such a DocVisitor, would it 
be
> welcomed?

Although - I'm concerned about "feature creep" in a package like doxygen.

The people I work with would love for me to us a spell checker on the
documentation i write...

-Duane

[Doxygen-develop] Spell checking

[Michael M. <Mic...@tt...>]

Hi there,

I'm starting to build up a bit of documentation using Doxygen, and realise
that I've made the odd spelling mistake.  It would help me if Doxygen would
check spellings while generating documentations and produce warnings.

Checking the lists archives, I haven't found anything significant about
spell checking in Doxygen.  Surely this has been considered before?

I was thinking that it would be simple to make a DocVisitor that together
with something like GNU aspell, could check all the observable text and
produce warnings for misspelt words.

Particularly this would be better than extracting the comments from the
source, and then running a spell checker as things like \a words or \code
blocks could automatically be skipped.

Anyone have any comments on this?  If I made such a DocVisitor, would it be
welcomed?

Cheers,

Mike

[Doxygen-develop] [PATCH] Word wrapping long class names in DOT diagrams

[David W. <da...@te...>]

I have noticed that when using the doxygen-generated inheritance
diagrams and collaboration diagrams, class names are always drawn on a
single line.  This can lead to needlessly large diagrams (4000+ pixels
wide) if you have a C++ class with several template arguments, for
example.

The following patch to doxygen 1.4.3 solves this problem for many of the
cases I tried, by trying to word-wrap the class name once it exceeds 30
characters.  Line breaks are inserted after space or comma.  The same
line-breaking method will also be used for arrow labels.=20

One inheritance graph (for a template class instantiated with 8 template
parameters) went from 4010 to 979 pixels width after this patch and is
much more readable.

Also, this patch corrects a small bug with collaboration diagrams.  When
multiple member variables have the same type, this was showing up in the
collaboration diagram as "m_one\nm_two\nm_three" next to the dashed
purple arrow, rather than showing "m_one", "m_two", "m_three" on
separate lines.

Regards

Dave


diff -ur doxygen-1.4.3.orig/src/dot.cpp doxygen-1.4.3/src/dot.cpp
--- doxygen-1.4.3.orig/src/dot.cpp      2005-04-18 02:55:55.000000000
+1000
+++ doxygen-1.4.3/src/dot.cpp   2005-06-14 12:41:17.000000000 +1000
@@ -561,15 +561,27 @@
   QCString result;
   const char *p=3Dl.data();
   char c;
+  int line=3D0;
   while ((c=3D*p++))
   {
+       ++line;
     switch(c)
     {
+      case '\n': result+=3D"\\n"; line=3D0; break;
       case '\\': result+=3D"\\\\"; break;
       case '<':  result+=3D"\\<"; break;
       case '>':  result+=3D"\\>"; break;
       case '|':  result+=3D"\\|"; break;
       case '"':  result+=3D"\\\""; break;
+      case ' ':
+      case ',':
+       // these are used to break lines over 30 characters
+       result +=3D c;
+       if(line >=3D 30 && strlen(p) > 1) {       // orphan control: =
don't
leave dangling '>' on last line
+         result +=3D "\\l   ";
+         line =3D 0;
+       }
+       break;
       default:   result+=3Dc; break;
     }
   }
@@ -1446,7 +1458,7 @@
           }
           else
           {
-            label+=3DQCString("\\n")+s;
+            label+=3DQCString("\n")+s;
           }
         }
         addClass(ucd->classDef,n,EdgeInfo::Purple,label,distance,0,

Re: [Doxygen-develop] BUG: Aliases not formatted

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

On 5/26/05, Randall, Larry <l-r...@ti...> wrote:
> =20
>=20
> Dimitri,=20
>=20
> In the 1.3.7 era, an alias was formatted in RTF output exactly as a
> Parameter, &c.  This formatting was lost somewhere between 1.3.7 and 1.4.=
1.=20
>=20
> The actual formatted output appears below.  "Syntax", "Path", and "Librar=
y"
> are aliases.=20

Ok, but you didn't mention how these aliases are defined. I could
imagine that is the
source of the problem, but at least this information is required to
reproduce the
problem. I would prefer that a bug report is filed with a self
contained example as
an attachment.

Regards,
  Dimitri

[Doxygen-develop] BUG: Aliases not formatted

[Randall, L. <l-r...@ti...>]

Dimitri,

In the 1.3.7 era, an alias was formatted in RTF output exactly as a =
Parameter, &c.  This formatting was lost somewhere between 1.3.7 and =
1.4.1.

The actual formatted output appears below.  "Syntax", "Path", and =
"Library" are aliases.

We, along with most others who need printable documentation in a strict =
format, must have the output in a defined format - using our approved =
styles.  [ We are stuck with Word as our "text processor".   :-(  ]  I =
have created a style sheet that converts the Doxygen styles to our =
styles.  Unfortunately, the style used for aliases is a text style - not =
a heading - and it does not match the style used for "Parameters".

(We would also prefer that the heading be the function without =
arguments:  i.e., "ExampleFunction()".)  REASON:  The "Ret_Type =
ExampleFunction (Object * p, InstNum a, Mode oMode, HwSetup * q)" is not =
as clear, and long headings create problems in the Table of Contents for =
printed documents.  This explains why we chose to have the syntax shown.

Fixing these problems leads to enormous amounts of wasted time, and =
makes it difficult to use Doxygen.

	Ret_Type ExampleFunction (Object * p, InstNum a, Mode oMode, HwSetup * =
q)
	ExampleFunction( )=20
	The ExampleFunction( ) call sets up the data structures for the =
particular instance of the device. It also checks for the availability =
of resource and flags error if it is not available. Hardware setup will =
be performed at the end of the open call only if the HwSetup Pointer =
supplied as the argument is not NULL.
	#include <ialg.h>=20
	 #include <node.h>
	Syntax:=20
			Ret_Type ExampleFunction (Object *p, InstNum a, Mode oMode, HwSetup =
*q);  =20
	Path =20
			\this\path\here
		Parameters:
			*p Pointer to the Object
			a The Instance Number (InstNum)
			oMode The desired Open Mode
			*q Pointer to the HwSetup structure
		Precondition:
			This is the pre-condition
		Postcondition:
			status =3D Open(myExample, 1, .........)
		Returns:
			DEF_OK =3D Successful open
			 Other value =3D Open failed (Error code is returned.)=20
		See also:
			doThis, doThat, doNothing
	Library:=20
			Example Library


Regards,=20
Larry Randall =20
OMAP(tm) Program Facilitation Office=20

[Doxygen-develop] Patch: Preprocessing DOT input files

[Michael M. <Mic...@tt...>]

Hi there,

There was a post on the doxygen-users list a few days ago asking if it is
possible to do something like the following:

/** blah blah 
\dot
graph G {
  a -- b
#if defined(ENABLE_C)
  b -- c
  c -- a
#endif
}
\enddot

*/

Basically this allows showing or hiding of nodes based on the pre-processor
defines.  As far as I've been able to workout, this cannot be done without
invoking an external pre-processor as part of a build step or script.

This feature is something I very much want, as I have a large diagram with a
few small parts which are optional depending on compile switches.  DOT
itself seems to like the idea of pre-processing as it ignores any lines that
start with a # character, so is safe to ignore and '#line' output, were the
pre-processor to make any.

There follows a patch that adds an option "PREPROCESS_DOT_FILES" to allow
DOT input files to be preprocessed.  I would be very grateful to know if
this patch can be included in a future version or Doxygen, or whether it
needs any changes to be acceptable.  

The patch can be applied in the following way:

$ tar -xzf doxygen-1.4.3.src.tar.gz
$ cd doxygen-1.4.3
$ patch -p1 < patchfile

Here is the patch:

diff -Naurw doxygen-1.4.3.orig/addon/doxywizard/config.l
doxygen-1.4.3/addon/doxywizard/config.l
--- doxygen-1.4.3.orig/addon/doxywizard/config.l	2005-05-16
20:38:16.000000000 +0100
+++ doxygen-1.4.3/addon/doxywizard/config.l	2005-05-24
22:57:11.358347200 +0100
@@ -2491,6 +2491,16 @@
                     TRUE
                  );
   cb->addDependency("ENABLE_PREPROCESSING");
+  cb = addBool(
+                    "PREPROCESS_DOT_FILES",
+                    "If the PREPROCESS_DOT_FILES tag is set to YES then
doxygen's preprocessor \n"
+                    "will be called on all files that are about to be
passed to DOT.  This \n"
+                    "allows pre-processor protections to be added around
nodes such that build \n"
+                    "defines can add or hide graph nodes.  The default
option is NO such that \n"
+                    "compatibility with older versions of Doxygen is
maintained. \n",
+                    FALSE
+                 );
+  cb->addDependency("ENABLE_PREPROCESSING");
 
//--------------------------------------------------------------------------
---------------------
   addInfo(  "External","Configuration::additions related to external
references   ");
 
//--------------------------------------------------------------------------
---------------------
diff -Naurw doxygen-1.4.3.orig/src/config.l doxygen-1.4.3/src/config.l
--- doxygen-1.4.3.orig/src/config.l	2005-05-12 20:19:42.000000000 +0100
+++ doxygen-1.4.3/src/config.l	2005-05-24 22:56:52.050584000 +0100
@@ -2491,6 +2491,16 @@
                     TRUE
                  );
   cb->addDependency("ENABLE_PREPROCESSING");
+  cb = addBool(
+                    "PREPROCESS_DOT_FILES",
+                    "If the PREPROCESS_DOT_FILES tag is set to YES then
doxygen's preprocessor \n"
+                    "will be called on all files that are about to be
passed to DOT.  This \n"
+                    "allows pre-processor protections to be added around
nodes such that build \n"
+                    "defines can add or hide graph nodes.  The default
option is NO such that \n"
+                    "compatibility with older versions of Doxygen is
maintained. \n",
+                    FALSE
+                 );
+  cb->addDependency("ENABLE_PREPROCESSING");
 
//--------------------------------------------------------------------------
---------------------
   addInfo(  "External","Configuration::additions related to external
references   ");
 
//--------------------------------------------------------------------------
---------------------
diff -Naurw doxygen-1.4.3.orig/src/dot.cpp doxygen-1.4.3/src/dot.cpp
--- doxygen-1.4.3.orig/src/dot.cpp	2005-04-17 17:55:56.000000000 +0100
+++ doxygen-1.4.3/src/dot.cpp	2005-05-24 23:44:22.929947200 +0100
@@ -29,6 +29,8 @@
 #include "docparser.h"
 #include "debug.h"
 #include "pagedef.h"
+#include "pre.h"
+#include "bufstr.h"
 
 #include <qdir.h>
 #include <qfile.h>
@@ -2714,6 +2716,24 @@
 #endif
   absOutFile+=outFile;
 
+  // Preprocess the file if needed */
+  if(Config_getBool("PREPROCESS_DOT_FILES"))
+  {
+    BufStr ppBuf(512);
+
+    preprocessFile(inFile, ppBuf);
+
+    // Rewrite the buffer to the input file
+    QFile file(inFile);
+    if (!file.open(IO_WriteOnly))
+    {
+      err("Could not open file %s for writing\n",inFile);
+    }
+    file.writeBlock( ppBuf.data(), ppBuf.curPos() );
+    file.close();
+  }
+
+
   // chdir to the output dir, so dot can find the font file.
   QCString oldDir = convertToQCString(QDir::currentDirPath());
   // go to the html output directory (i.e. path)



Cheers,

Mike

[Doxygen-develop] Problem to compile the wintool doxygen project for windows

[Pierre B. <pbl...@lo...>]

I'm trying to compile doxygen for Windows using Microsoft's Visual C++
(version 6.0).

I use the .dsw file found in the wintools directory provided with the source
distribution.

Unfortunatly while linking I have the message belows which warns me about 2
errors, and I can't build the .exe :

>Linking...
>scanner.obj : error LNK2001: unresolved external symbol "bool __cdecl
parseCommentBlock(class Entry *,class QCString const &,class QCString >const
&,int,bool,bool,enum Protection &)"
(?parseCommentBlock@@YA_NPAVEntry@@ABVQCString@@1H_N2AAW4Protection
>@@@Z)
>Debug/Doxygen.exe : fatal error LNK1120: 1 unresolved externals
>Error executing link.exe.

To resolve this problem I had to change in the project the location of the
commentscan.h file from the "External Dependencies" folder to the "Source
Files" folder of "Doxygen Files".

I would like to know from the .dsw file maintainer or anyone else, whether
this change may affect the final result of the wintools project, and if it
was possible to update this file.

Regards.

Pierre

[Doxygen-develop] Member group syntax

[Max B. <ee4...@ma...>]

In Doxygen 1.4.1, this worked:

/** @{
 * This is a member group. */
#define FOO "bar"
/** @} */

In Doxygen 1.4.2, member groups got seriously broken.

In Doxygen 1.4.2-20050410, member groups are a lot better, but the above 
syntax still doesn't work.
Is it valid? Or was it merely accidental that it used to work?


Thanks,

Max.

[Doxygen-develop] API Doc of Doxygen Parse Tree available ?

[Binsan <bk...@da...>]

I am trying to implement a new output generator by modifying the
RTFGenerator. But I am having trouble understanding the parsing mechanism. 

As I am lost many times tracing the code, I wonder if there is any extra
documentation for developers (besides that already present in the source
code) of the structure of the DocNode and its children.

Any other documentation for developers?

Binsan

[Doxygen-develop] Translators revisited (searching for volunteers)

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

(Posted to doxygen-develop, copied to doxygen-users.)

Translators revisited? Again? (Dust covers the old doc.)

Do you think that the things below should have
some wiki page (for discussion)?

This is related to possible future implementation
of the translation of Doxygen output to the
supported human languages. The below mentioned
document was last touched in August 2001 (when
Doxygen's XML output support just begun or even
was not there -- I am not sure). Some experimental=20
work was also done in that time to replace the code=20
of the translator classes by string templates that could
possibly be placed outside the doxygen executable,
in text files (entity definitions, or so).=20

The full doxygenable source and the html of=20
the document is available at
http://www.skil.cz/doxygen/TranslatorsRevisited.zip
(Note that it was done more than 3 years earlier,=20
with older Doxygen.)

Some experimental C++ sources that show how the
things could be done are available at=20
http://www.skil.cz/doxygen/Conversion.zip
It contains also doxy.exe (Windows) and the
generated results from the translator_xx.h files
(as mentioned in the document).

The later http://www.skil.cz/doxygen/Conversion2.zip
contains a source that is a bit newer but without
the things around. I believe it was intended to
use with the slightly changed doxygen sources.

The http://www.skil.cz/doxygen/dox_revisited.zip
contains some sources that show how the changes
could be incorporated into the doxygen sources.
Some tricks mentioned in the "Translators revisited".

If you are willing to help, please, feel free to
contact me (or Dimitri) to discuss the details.


Some motivation for the changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

Recently, Johann 'Myrkraverk' Oskarsson asked some
details about translating some documentation to
another human language. After some clarification
he wrote:
 =20
   Ideally, I'd like a system, similar to Qts tr()
   system, where doxygen would generate
   translation files, and then use them to
   generate the docs.

   I can imagine this could work with the
   experimental XML output, if that can be used to
   generate the rest of the docs (or if that
   feature is trivial to add).


Possibly, some of the needs could be solved using
the approach. It would also be nice to get some
developer that knows XML and also the XML
generated by Doxygen.

The following text is the excerpt from the
"Translators revisited" old document:

    Motivation
   =20
    Language support is now implemented via classes
    based on the abstract class Translator. The main
    reason is that, generally, it is difficult to
    produce nicely readable sentences from fragments
    of the chosen language.
   =20
    It is impossible to generalize the process of
    gluing the fragments together independently on the
    language. It's because the language rules cannot
    be generally algoritmized. Often, the whole
    sentences must be generated. It was found easier
    to do it programmatically, because the language
    maintainer can modify the sentence according to
    the passed arguments.
   =20
    Basically, the generated sequences may contain
    document-related generated parts, e.g. single
    identifiers or lists of identifiers. The generated
    sentences and fragments may be modified via
    argument values like first_capital, plural, etc.
   =20
    On the other hand, it would be much easier for the
    language maintainers or even for end users to
    maintain the language via editing text files,
    without need to recompile whole doxygen.
   =20
    The idea is based on implementing a mechanism that
    will use templates for whole sentences. The
    fundamental question is How?

(Detailed questions, some answers, and steps=20
planned to implement everything can be found=20
inside the document.)

Regards,=20
  Petr

--=20
Petr Prikryl (prikrylp at skil dot cz)=20

Re: [Doxygen-develop] Re: Doxygen and C++/.NET

[Christian B. <chr...@am...>]

Allo Jason!

As a suggestion, you may want to try setting the PREDEFINED tag to some =
meaningful standard C++ definition for the Managed C++ keyword in =
combination with the ENABLE_PREPROCESSING, MACRO_EXPANSION and =
EXPAND_ONLY_PREDEF tags.

As an example, PREDIFINED tags were done for the boilerplate macros of =
the Microsoft's ATL and MFC libraries. You can find these definitions in =
the doxygen documentation under the Preprocessing heading.

I think this should get you going without the need for a code filter

Regards,

Christian
  ----- Original Message -----=20
  From: Jason Mills=20
  To: dox...@li...=20
  Sent: Monday, March 28, 2005 10:07 AM
  Subject: [Doxygen-develop] Re: Doxygen and C++/.NET


  Thanks for the response, but not exactly what I'm looking for. Maybe =
my=20
  question was not clear (... or you choose to answer it differently,=20
  which is fine :-) ). I'm looking to *use* Doxygen to create=20
  documentation for code written in Managed C++ and the upcoming =
C++/CLI.=20
  I'm not trying to compile Doxygen to work on the .NET platform, =
although=20
  that is cool.

  With the exception of your email, no one as responded to my original=20
  question. So I assume no one as used Doxygen with Managed C++. Thats a =

  pity. But I think Doxygen should support the upcoming C++/CLI. There =
is=20
  no doubt, it will be used significantly on the Windows platform.

  Thanks, anyway.

  Jason

  Hendy Irawan wrote:
  >   > Two few related questions:
  >   >
  >   > - Have anyone used doxygen with Managed C++ (.NET)? If so, are =
there
  >   >   any filters available to handle managed C++ keywords, such as
  >   >   __interface?
  >   >
  >   > - Will there ever be support for the soon to be available =
C++/CLI?
  >=20
  > I'm sure about the "users" point of view.
  >=20
  > But from the "develop" POV... I tried to do this:
  > - Compile doxygen as static lib (need to do some project =
configuration
  > changes here, I guess on most other dependent libs too)
  > - Create a Managed C++ project library/assembly
  > - Link that assembly with the static lib (need to do some project
  > configuration stuff, use "mixed mode" as opposed to pure IL)
  > - Export functions that you want in that assembly, that calls =
doxygen functions
  > - Create another "host" project in C#, references that Managed C++ =
assembly
  > - Call that assembly function in this host project
  >=20
  > It took some (a lot of) time to get it right. But when it's done, it
  > feels (kinda') great. "Hey, Doxygen running on .NET" ;-) It doesn't
  > parse .NET stuff, it just runs on .NET. :-)
  >=20
  > --
  > Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
  >=20
  >=20



  -------------------------------------------------------
  SF email is sponsored by - The IT Product Guide
  Read honest & candid reviews on hundreds of IT Products from real =
users.
  Discover which products truly live up to the hype. Start reading now.
  http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
  _______________________________________________
  Doxygen-develop mailing list
  Dox...@li...
  https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Re: Doxygen and C++/.NET

[Jason M. <jm...@cs...>]

Thanks for the response, but not exactly what I'm looking for. Maybe my 
question was not clear (... or you choose to answer it differently, 
which is fine :-) ). I'm looking to *use* Doxygen to create 
documentation for code written in Managed C++ and the upcoming C++/CLI. 
I'm not trying to compile Doxygen to work on the .NET platform, although 
that is cool.

With the exception of your email, no one as responded to my original 
question. So I assume no one as used Doxygen with Managed C++. Thats a 
pity. But I think Doxygen should support the upcoming C++/CLI. There is 
no doubt, it will be used significantly on the Windows platform.

Thanks, anyway.

Jason

Hendy Irawan wrote:
>   > Two few related questions:
>   >
>   > - Have anyone used doxygen with Managed C++ (.NET)? If so, are there
>   >   any filters available to handle managed C++ keywords, such as
>   >   __interface?
>   >
>   > - Will there ever be support for the soon to be available C++/CLI?
> 
> I'm sure about the "users" point of view.
> 
> But from the "develop" POV... I tried to do this:
> - Compile doxygen as static lib (need to do some project configuration
> changes here, I guess on most other dependent libs too)
> - Create a Managed C++ project library/assembly
> - Link that assembly with the static lib (need to do some project
> configuration stuff, use "mixed mode" as opposed to pure IL)
> - Export functions that you want in that assembly, that calls doxygen functions
> - Create another "host" project in C#, references that Managed C++ assembly
> - Call that assembly function in this host project
> 
> It took some (a lot of) time to get it right. But when it's done, it
> feels (kinda') great. "Hey, Doxygen running on .NET" ;-) It doesn't
> parse .NET stuff, it just runs on .NET. :-)
> 
> --
> Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
> 
> 

[Doxygen-develop] Re: Doxygen and C++/.NET

[Hendy I. <gau...@gm...>]

  > Two few related questions:
  >
  > - Have anyone used doxygen with Managed C++ (.NET)? If so, are there
  >   any filters available to handle managed C++ keywords, such as
  >   __interface?
  >
  > - Will there ever be support for the soon to be available C++/CLI?

I'm sure about the "users" point of view.

But from the "develop" POV... I tried to do this:
- Compile doxygen as static lib (need to do some project configuration
changes here, I guess on most other dependent libs too)
- Create a Managed C++ project library/assembly
- Link that assembly with the static lib (need to do some project
configuration stuff, use "mixed mode" as opposed to pure IL)
- Export functions that you want in that assembly, that calls doxygen functions
- Create another "host" project in C#, references that Managed C++ assembly
- Call that assembly function in this host project

It took some (a lot of) time to get it right. But when it's done, it
feels (kinda') great. "Hey, Doxygen running on .NET" ;-) It doesn't
parse .NET stuff, it just runs on .NET. :-)

--
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center


-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

Re: [Doxygen-develop] doxygen patch for always anchoring lines in HTML output

[Rob H. <ti...@ge...>]

Not sure if I forgot to attach it or if the list strips it so I'll try
again.. :)

-- 
rob holland - [ ti...@ge... ] - Gentoo Audit Team
[ 5251 4FAC D684 8845 5604  E44F D65C 392F D91B 4729 ]

[Doxygen-develop] doxygen patch for always anchoring lines in HTML output

[Rob H. <ti...@ge...>]

Hi,

As part of my work in adding features to doxygen to make it useful for
spotting common coding mistakes I'd like to ask that the attached patch
be applied. It makes sure that all lines have anchors in the HTML so
that I can refer to any source line from a source scanner report, such
as the output of rats/flawfinder and so on.

An example doxygen output with this patch and its use can be seen at:

http://dev.gentoo.org/~tigger/audit/sendmail_8_13_1_tar_gz/

I apologise for the uglyness of that page, but I'm far from the point in
my project where I start worrying about visual appeal ;)

You will see that clicking on any source code line will take you to the
relevant line in the doxygen-marked-up source code.

I have to say doxygen is an excellent utility. Kudos :)

Thanks,

Rob

-- 
rob holland - [ ti...@ge... ] - Gentoo Audit Team
[ 5251 4FAC D684 8845 5604  E44F D65C 392F D91B 4729 ]

RE: [Doxygen-develop] Problems at last release?...

[<ca...@cr...>]

	Hi!
	Thank's. Work fine.=20

-----Original Message-----
From: Dimitri van Heesch [mailto:do...@gm...]=20
Sent: Tuesday, March 15, 2005 9:59 PM
To: =FE=C5=CC=D0=C1=CE=CF=D7 =E1=CC=C5=CB=D3=C1=CE=C4=D2 =
=F7=C9=D4=C1=CC=D8=C5=D7=C9=DE
Cc: doxydev
Subject: Re: [Doxygen-develop] Problems at last release?...

On Tue, 15 Mar 2005 14:10:20 +0300, =FE=C5=CC=D0=C1=CE=CF=D7 =
=E1=CC=C5=CB=D3=C1=CE=C4=D2 =F7=C9=D4=C1=CC=D8=C5=D7=C9=DE =
<ca...@cr...> wrote:
>         Hi!
> Is there a bug or new funtionality?

Bugs, the first pass comment scanner was completely rewritten (separated =
from the language parser), so still expect some problems in corner =
cases. But please report them in the way you did and I'll fix them ASAP.

Regards,
  Dimitri

>=20
> 1. The doxygen comments on code
> -----------------------------------
> /*!
>  * \brief aaaa
>  * \note qqq
>  */
> class A{}
> -----------------------------------
> didn't look same as code
> -----------------------------------
> /*!
>  * \brief aaaa
>  *
>  * \note qqq
>  */
> class A{}
> -----------------------------------
> I think, that new tag end previous tag.
>=20
> 2. The doxygen comments on code
> -----------------------------------
> /*!
>  *\brief 1111
>  *
>  * text
>  */
> class A{};
> -----------------------------------
> Didn't look same as code
> -----------------------------------
> /*!
>  * \brief 1111
>  *
>  * text
>  */
> class A{};
> -----------------------------------
> Must I add space before backslash symbol?
>

Re: [Doxygen-develop] Problems at last release?...

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

On Tue, 15 Mar 2005 14:10:20 +0300, =D0=A7=D0=B5=D0=BB=D0=BF=D0=B0=D0=BD=D0=
=BE=D0=B2 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=
=B8=D1=82=D0=B0=D0=BB=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ca...@cr...> wrote:
>         Hi!
> Is there a bug or new funtionality?

Bugs, the first pass comment scanner was completely rewritten
(separated from the language parser), so still expect some problems in
corner cases. But please report them in the way you did and I'll fix
them ASAP.

Regards,
  Dimitri

>=20
> 1. The doxygen comments on code
> -----------------------------------
> /*!
>  * \brief aaaa
>  * \note qqq
>  */
> class A{}
> -----------------------------------
> didn't look same as code
> -----------------------------------
> /*!
>  * \brief aaaa
>  *
>  * \note qqq
>  */
> class A{}
> -----------------------------------
> I think, that new tag end previous tag.
>=20
> 2. The doxygen comments on code
> -----------------------------------
> /*!
>  *\brief 1111
>  *
>  * text
>  */
> class A{};
> -----------------------------------
> Didn't look same as code
> -----------------------------------
> /*!
>  * \brief 1111
>  *
>  * text
>  */
> class A{};
> -----------------------------------
> Must I add space before backslash symbol?
>

[Doxygen-develop] Problems at last release?...

[<ca...@cr...>]

	Hi!
Is there a bug or new funtionality?

1. The doxygen comments on code
-----------------------------------
/*!
 * \brief aaaa
 * \note qqq
 */
class A{}
-----------------------------------
didn't look same as code=20
-----------------------------------
/*!
 * \brief aaaa
 *
 * \note qqq
 */
class A{}
-----------------------------------
I think, that new tag end previous tag.


2. The doxygen comments on code
-----------------------------------
/*!=20
 *\brief 1111
 *
 * text
 */
class A{};
-----------------------------------
Didn't look same as code
-----------------------------------
/*!=20
 * \brief 1111
 *
 * text
 */
class A{};
-----------------------------------
Must I add space before backslash symbol?

[Doxygen-develop] RE: Doxygen: Translator cz, kr, ru

[<ca...@cr...>]

	Hi!
	Petr, you russian is good! But when I check this, I do not find decode =
in last function, so new russian update attached.

-----Original Message-----
From: Petr Prikryl [mailto:Pr...@sk...]=20
Sent: Tuesday, March 15, 2005 11:25 AM
To: Dimitri van Heesch
Cc: =FE=C5=CC=D0=C1=CE=CF=D7 =E1=CC=C5=CB=D3=C1=CE=C4=D2 =
=F7=C9=D4=C1=CC=D8=C5=D7=C9=DE; jun...@gm...
Subject: Doxygen: Translator cz, kr, ru

Hi Dimitri,
... and copied "Hi" to Alexandr and SooYoung (is this the first name?)

I am sending the updated translator_cz.h (again -- forgot to change the =
base class).

I did a minor correction of comment in
the Russian translator. It is the one that was posted recenly in doxydev =
mailing list.=20
(I did it when looking inside; the Decode() changed to decode() -- for =
Alexandr.
I was just curious whether jEdit will display the azbuka characters and =
whether I am still able to read and understand the Russian language ;).

I have slightly corrected the Korean
translator to use newer translator adapter, as reported by =
translator.py. (No, I cannot read the Korean texts. And it is not the =
jEdit fault  ;)

I have changed the line endings of all
mentioned translators to unix ones.

Regards,
  Petr

P.S. I did not experiment with corrections related to VC 7.1 yet -- =
waiting for next CVS release (I am quite busy now).


--
Petr Prikryl (pri...@sk...)=20

[Doxygen-develop] Russian translation update

[<ca...@cr...>]

	Hi!
	translator_ru attached.

RE: [Doxygen-develop] Problem French accent under linux

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

Hi Xavier,

Xavier Outhier wrote...
> [...]
> I got a user feedback about a problem for vizualising
> the HTML doc in French under Linux (but it's correct
> under Windows).
>=20
> She made the following settings:
>   USE_WINDOWS_ENCODING set to NO
>   OUTPUT_LANGUAGE set to French
>=20
> I feel the problem arise because I'm under Windows, using
> French ASCII in the translator_fr.h.

My guess is that French encoding for Unix is different
than French encoding for Windows. This means that
your translator should return the strings differently.
based on the USE_WINDOWS_ENCODING. It is=20
only a configuration parameter that _can_ be tested
in your translator_fr.h.

If the encodings for Windows/Unix are not identical,=20
the idLanguageCharset() should test the=20
USE_WINDOWS_ENCODING and return the
appropriate string. In such case, you should
also define something like decode() that
also tests the USE_WINDOWS_ENCODING=20
and converts encoding of strings returned=20
by the translator methods. Have a look=20
at translator_cz.h to see how the things=20
can be done.

> I have two questions:
>   -1 Will it solve the problem if I use the HTML entity
>      in the header file?

I am not sure what you mean by that, but probably no.
If you run doxygen in Linux, then the documented
sources probably use the encoding for unix.=20
The translator adds strings that should be also converted
to unix encoding -- otherwise text with both encodings
would be mixed (the unix text from sources and the windows
texts from doxygen.

>   -2 Will it not disturb the other output: Latex, RTF or
>      whatever.
>      If yes how to solve the problem.

The same problem -- possible mixing of two encodings.
You have to enhance your translator_fr.h ;)  Feel free
to ask for details.

Regards,=20
  Petr


--=20
Petr Prikryl (prikrylp at skil dot cz)=20

[Doxygen-develop] Problem French accent under linux

[Xavier O. <xav...@an...>]

Hi,

I got a user feedback about a problem for vizualising
the HTML doc in French under Linux (but it's correct
under Windows).

She made the following settings:
  USE_WINDOWS_ENCODING set to NO
  OUTPUT_LANGUAGE set to French

I feel the problem arise because I'm under Windows, using
French ASCII in the translator_fr.h.

I have two questions:
  -1 Will it solve the problem if I use the HTML entity
     in the header file?

  -2 Will it not disturb the other output: Latex, RTF or
     whatever.
     If yes how to solve the problem.

Xavier  - the French "localisator"

[Doxygen-develop] Re: Doxygen and C++/.NET

[Jason M. <jm...@cs...>]

My apologies. I meant to post the following to the user group!

Jason

 > Two few related questions:
 >
 > - Have anyone used doxygen with Managed C++ (.NET)? If so, are there
 >   any filters available to handle managed C++ keywords, such as
 >   __interface?
 >
 > - Will there ever be support for the soon to be available C++/CLI?