doxygen-users — List for users of doxygen

[Doxygen-users] Grouping in an enum

[Leon C. <leo...@sy...>]

I have a large enum (a couple of hundred entries), whose members need 
documenting and whose members could do to be grouped into several 
categories. So I tried to create some member groups:
enum MyEnum {
	///@name First Group
	//@{
	/// Description of first item
	FirstItem,
	/// Description of second item
	SecondItem,
	//@}
	///@name Second Group
	//@{
	/// Description of third item
	ThirdItem,

	And so on.

However, no groups appeared so I assume I'm not allowed to group the 
members of an enum. Am I doing something wrong, or can I suggest that this 
would be a useful feature?

Leon



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify pos...@sy... and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

Re: [Doxygen-users] FW: Doxygen-users digest, Vol 1 #73 - 10 msgs

[Victor A. W. Jr. <va...@ru...>]

gee, you don't want
argument_name  argument type
like Pascal also?

At Friday 2001/07/13 05:54, you wrote:



>Joe,
>
>I haven't looked at the code (I'm a bit under the thumb at work at the
>moment) but would it be possible (pretty please) while you are in there
>to examine the possiblilty of setting up formatting using a plugin
>approach ?
>
>For readability I would like the tool to document members in a
>pascal-like format ie
>
>         member_name   (args)   : return_value
>
>... so that for a member function we would have output looking like ...
>
>fn_name  | (                                   | : return_value
>          |   argument_type1  argument_name1,   |
>          |   argument_type2  argument_name2    |
>          |  )                                  |
>
>
>NB : The bar '|' symbol indicates the edge of an html table.
>
>This keeps all the member names in the left hand column which makes it
>very easy for the eye.
>Also as in your suggestion splitting the args onto separate lines makes
>for easy reading of the signature.
>
>
>The reason we want this is that some of our type names are very long so
>with the existing doxygen format ....
>
>return_type  | fn_name (argument_type1  argument_name1, argument_type2
>argument_name2 )
>
>.... the fn_name and args are pushed right across the page and it
>quickly becomes cluttered and a unreadable.
>
>
>After all its documentation and if its not easily readable then its not
>much use.
>
>
>If a plugin approach were used then it would simplify the task of
>format customisation in future.
>
>Cheers JL
>
>
>
>Message: 9
>From: joe bester <be...@mc...>
>To: Dimitri van Heesch <di...@st...>
>Date: Thu, 12 Jul 2001 12:32:57 -0500
>Cc: Dox...@li...
>Subject: [Doxygen-users] Customizing look in Doxygen
>Reply-To: dox...@li...
>
>Dimitri,
>
>I've done some work to customize the output of doxygen to match our
>project's
>web design, and coding standard. Much of this has been accomplished via
>style
>sheets, but there some things, such as the format of function
>signatures have
>been necessary to handle as source code modifications.
>
>For example, we prefer to have functions displayed like this:
>
>return_type
>function_name(
>     argument_type1                    argument_name1,
>     argument_type2                    argument_name2)
>
>Rather than doxygen's default
>
>return_type function_name(argument_type1 argument_name1,
>argument_type2,
>argument_name2)
>
>This is mostly because we tend to have rather long function
>names and argument types.
>
>If I were to submit a patch to do this sort of formattting, would it be
>accepted? Perhaps if I wrapped it in a configuration option?
>
>joe
>
>
>
>Visit our website at http://www.ubswarburg.com
>
>This message contains confidential information and is intended only
>for the individual named.  If you are not the named addressee you
>should not disseminate, distribute or copy this e-mail.  Please
>notify the sender immediately by e-mail if you have received this
>e-mail by mistake and delete this e-mail from your system.
>
>E-mail transmission cannot be guaranteed to be secure or error-free
>as information could be intercepted, corrupted, lost, destroyed,
>arrive late or incomplete, or contain viruses.  The sender therefore
>does not accept liability for any errors or omissions in the contents
>of this message which arise as a result of e-mail transmission.  If
>verification is required please request a hard-copy version.  This
>message is provided for informational purposes and should not be
>construed as a solicitation or offer to buy or sell any securities or
>related financial instruments.
>
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>http://lists.sourceforge.net/lists/listinfo/doxygen-users

Victor A. Wagner, Jr.
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"

[Doxygen-users] FW: Doxygen-users digest, Vol 1 #73 - 10 msgs

[<Joh...@ub...>]

Joe, 

I haven't looked at the code (I'm a bit under the thumb at work at the 
moment) but would it be possible (pretty please) while you are in there 
to examine the possiblilty of setting up formatting using a plugin 
approach ? 

For readability I would like the tool to document members in a 
pascal-like format ie

	member_name   (args)   : return_value

.. so that for a member function we would have output looking like ...

fn_name  | (                                   | : return_value
         |   argument_type1  argument_name1,   |
         |   argument_type2  argument_name2    |
         |  )                                  |


NB : The bar '|' symbol indicates the edge of an html table.

This keeps all the member names in the left hand column which makes it 
very easy for the eye.  
Also as in your suggestion splitting the args onto separate lines makes 
for easy reading of the signature.


The reason we want this is that some of our type names are very long so 
with the existing doxygen format ....

return_type  | fn_name (argument_type1  argument_name1, argument_type2  
argument_name2 )

... the fn_name and args are pushed right across the page and it 
quickly becomes cluttered and a unreadable.


After all its documentation and if its not easily readable then its not 
much use.


If a plugin approach were used then it would simplify the task of 
format customisation in future.

Cheers JL



Message: 9
From: joe bester <be...@mc...>
To: Dimitri van Heesch <di...@st...>
Date: Thu, 12 Jul 2001 12:32:57 -0500
Cc: Dox...@li...
Subject: [Doxygen-users] Customizing look in Doxygen
Reply-To: dox...@li...

Dimitri,

I've done some work to customize the output of doxygen to match our 
project's 
web design, and coding standard. Much of this has been accomplished via 
style 
sheets, but there some things, such as the format of function 
signatures have 
been necessary to handle as source code modifications.

For example, we prefer to have functions displayed like this:

return_type
function_name(
    argument_type1                    argument_name1,
    argument_type2                    argument_name2)

Rather than doxygen's default

return_type function_name(argument_type1 argument_name1, 
argument_type2, 
argument_name2)

This is mostly because we tend to have rather long function 
names and argument types.

If I were to submit a patch to do this sort of formattting, would it be 
accepted? Perhaps if I wrapped it in a configuration option?

joe



Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

[Doxygen-users] pasting generated html page into generated html page

[Greger H. <gre...@ya...>]

Hello,
I need to do a documentation and with a custom 'layout'. Just want to
include the classes.html generated by doxygen within a custom page (
created with the \page command ). Now, as both are generated at the same

time it doesn't seem to be possible ( or am I just stupid :) ? ) to use
the \htmlinclude command to paste the classes.html page into the custom
page. So, is there another way to do this?



--
Greger Haga
Finland
ICQ 120338800
HTTP://www.geocities.com/gregerhaga
http://counter.li.org/



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [Doxygen-users] Customizing look in Doxygen

[Christoph K. <ko...@in...>]

be...@mc... said:
> If I were to submit a patch to do this sort of formattting, would it
> be  accepted? Perhaps if I wrapped it in a configuration option? 

I certainly second your proposal. Dimitri, what do you think?

Cheers, Christoph

[Doxygen-users] RE: Customizing look in Doxygen

[Don M. <dmc...@In...>]

>For example, we prefer to have functions displayed like this:
>
>return_type
>function_name(
>    argument_type1                    argument_name1,
>    argument_type2                    argument_name2)
>
>Rather than doxygen's default
>
>return_type function_name(argument_type1 argument_name1, argument_type2,
>argument_name2)

I, for one, would *love* to have doxygen show functions like that. I
encourage you  to submit that patch, but it probably should have a config
option, since other users are accustomed to the old style.

Thanks,

Don McClimans

Re: [Doxygen-users] Duplicate Parameters section?

[Jens S. <jen...@hr...>]

On Thu, 12 Jul 2001 ag...@pa... wrote:

> Hello!
>
> We have the same problem using the Win32 doxygen version. I've try several
> more simple parameter combinations but until now this persists. (Even the
> own Doxygen doc samples have duplicate params) Any idea?
>
> Antonio Gil
> PATANEGRA Soft
> Sevilla (SPAIN)
>

doxygen 1.2.8 contains a bug. Please use 1.2.8.1 instead.

changelog:

Due to some annoying bugs in release 1.2.8, I've decided to put out a
bug fix release labelled 1.2.8.1. Here is what has been fixed/changed:
-----------------------------------------------------------------
+ BUG: Parameters appeared in the documentation for undocumented
       arguments (and twice if they were also documented with @param).
[snip]

RE: [Doxygen-users] Customizing look in Doxygen

[CHUVALA, K. G. (JSC-D. (USA) <kei...@js...>]

> From: joe bester [mailto:be...@mc...]

> For example, we prefer to have functions displayed like this:
>
> return_type
> function_name(
>     argument_type1                    argument_name1,
>     argument_type2                    argument_name2)

I'd certainly welcome this addition.  Like Joe, our team likes to use
lengthy descriptive identifier names (vestiges of a sordid past working in
COBOL, perhaps?)

The configuration option idea is a good one, too; no sense forcing everyone
to do things the RIGHT way, er, I mean MY way <g>.

kgc

______________________________________
Keith G. Chuvala
Space Operations Computing (SpOC) Team
Johnson Space Center
Houston, Texas, USA

Re: [Doxygen-users] Duplicate Parameters section?

[<ag...@pa...>]

Hello!

We have the same problem using the Win32 doxygen version. I've try several 
more simple parameter combinations but until now this persists. (Even the 
own Doxygen doc samples have duplicate params) Any idea?

Antonio Gil
PATANEGRA Soft
Sevilla (SPAIN)

[Doxygen-users] Customizing look in Doxygen

[joe b. <be...@mc...>]

Dimitri,

I've done some work to customize the output of doxygen to match our project's 
web design, and coding standard. Much of this has been accomplished via style 
sheets, but there some things, such as the format of function signatures have 
been necessary to handle as source code modifications.

For example, we prefer to have functions displayed like this:

return_type
function_name(
    argument_type1                    argument_name1,
    argument_type2                    argument_name2)

Rather than doxygen's default

return_type function_name(argument_type1 argument_name1, argument_type2, 
argument_name2)

This is mostly because we tend to have rather long function 
names and argument types.

If I were to submit a patch to do this sort of formattting, would it be 
accepted? Perhaps if I wrapped it in a configuration option?

joe

[Doxygen-users] C++-ism in LaTeX documentation

[joe b. <be...@mc...>]

The section containing structs and unions is labelled "Class Documentation" 
(in the English translation) even when the OPTIMIZE_OUTPUT_FOR_C is set to 
YES. The attached patch renames that to be "Data Structure Documentation" in 
that case.

joe

[Doxygen-users] external references (patch)

[joe b. <be...@mc...>]

Recently, I've been doing some work to integrate documentation from various 
subprojects using doxygen's tag file mechanism. I've run into a couple of
limitations:

- Can not link to @anchors in the main page on external packages.
- All external modules and pages are linked to or appended (even the TODO
  page, etc), even when EXTRACT_ALL is set to NO.

I've attached a patch which (I think) fixes these problems. This patch is 
made against the 1.2.8 release.

joe

Re: [Doxygen-users] C functions

[joe b. <be...@mc...>]

On Wed, Jul 11, 2001 at 04:17:22PM +0200, Kremer Markus (PN-SYS/DSA) wrote:
> Hello,
> is it possible to list my functions in the compound list?
> Or can i create a 'canvas' for all my c functions?
> I don't want to use "File Members" for searching my functions.
> 
> best regards,
> 
> Markus

See the second part to the answer to FAQ #3
(http://www.stack.nl/~dimitri/doxygen/faq.html)

joe

Re: [Doxygen-users] RPM for redhat 6.2?

[Jens S. <jen...@hr...>]

I attached doxygen.spec, please use this file.

On Thu, 12 Jul 2001, Jens Seidel wrote:

> On Thu, 12 Jul 2001, Ronald van Eijck wrote:
>
> > Hi,
> >
> > Are there RPM's that can be used with Redhat 6.2? I've tried to install the RH 7.x RPM but it has lots of dependencies for 7.x rpm's which have dependencies on other 7.x rpms etc. etc.
> >
> > I am now using 1.2.1 (the latest release I could find an RPM for) but I'd like to move to the latest & greatest.
> >
> > C'ya,
> >
> >     Ronald
> > Œréî±ê왨¥Šx%ŠËC£ z{¬z»%ŠËl²‹«qç讧zØm¶Ÿ¿þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?vŒréî±êì
>
> The doxygen source archive contains the rpm spec file
> packages/rpm/doxygen.spec. I use this file to create rpm packages for my
> Suse 7.2 system, but it should be possible to use this with other
> distributions too.
>
> Please try the following steps:
>
> copy doxygen-1.2.8.1.src.tar.gz to /usr/src/redhat/SOURCES (I hope that's
> correct, Suse uses /usr/src/packages/SOURCES)
>
> copy the spec file to /usr/src/redhat/SPECS
>
> rpm -bb /usr/src/redhat/SPECS/doxygen.spec # bb = build binary
>
> The last command creates the rpm file (you can find it in
> /usr/src/redhat/RPMS/...)
>
> The spec file uses the BuildRoot feature of rpm, so you cannot destroy
> system files, even if the build fails.
> If you need to modify doxygen.spec, send me the new file!
>
> Regards
> Jens Seidel
>
>

Re: [Doxygen-users] RPM for redhat 6.2?

[Jens S. <jen...@hr...>]

On Thu, 12 Jul 2001, Ronald van Eijck wrote:

> Hi,
>
> Are there RPM's that can be used with Redhat 6.2? I've tried to install the RH 7.x RPM but it has lots of dependencies for 7.x rpm's which have dependencies on other 7.x rpms etc. etc.
>
> I am now using 1.2.1 (the latest release I could find an RPM for) but I'd like to move to the latest & greatest.
>
> C'ya,
>
>     Ronald
> Œréî±ê왨¥Šx%ŠËC£ z{¬z»%ŠËl²‹«qç讧zØm¶Ÿ¿þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?vŒréî±êì

The doxygen source archive contains the rpm spec file
packages/rpm/doxygen.spec. I use this file to create rpm packages for my
Suse 7.2 system, but it should be possible to use this with other
distributions too.

Please try the following steps:

copy doxygen-1.2.8.1.src.tar.gz to /usr/src/redhat/SOURCES (I hope that's
correct, Suse uses /usr/src/packages/SOURCES)

copy the spec file to /usr/src/redhat/SPECS

rpm -bb /usr/src/redhat/SPECS/doxygen.spec # bb = build binary

The last command creates the rpm file (you can find it in
/usr/src/redhat/RPMS/...)

The spec file uses the BuildRoot feature of rpm, so you cannot destroy
system files, even if the build fails.
If you need to modify doxygen.spec, send me the new file!

Regards
Jens Seidel

[Doxygen-users] is this a bug ? / feature request

[Kremer M. (PN-SYS/DSA) <Mar...@Te...>]

Hello,
i found a strange feature of doxygen.
The following code does not generate two modules under 1.2.3 and 1.2.8.1 as
it should.

/** \defgroup cfn global c functions
  * \brief these are all used c functions
  *
  * If it does not work for you, please use a newer doxygen version(>1.2.7).
  * 
  * This is a list of all globel c functions. Please note, that
  * you have to fence them with two comment blocks.
\verbatim

/** \addtogroup cfn
    @{ */

and

/** @} */

\endverbatim
 *  This can be done either in your .h or your .c file.
 */

/** \defgroup note what to do if it does not show your functions
  *
  * If it does not work for you, please use a newer doxygen version(>1.2.3).
  * You can check your version with 'doxygen -v'.
 */

 /** \fn dummy
  \ingroup note
  */
 

Feature request:
Is there a possibility to destinguish doxygen versions?
i want to show a warning only if someone uses 1.2.3.

Even better would be a something like \hasfeature (addtogroup) ...
\endfeature

Or is it possible to combine it with the \if statement(\if
hasnot(addtogroup) ..\endif).


Best Regards

Markus

RE: [Doxygen-users] Changing the standard header

[Stephen G. <ste...@cl...>]

No need to change any code - just set your config file; look in the
manual for HTML_FOOTER and HTML_HEADER.

Stephen Goudge

-----Original Message-----
From: dox...@li...
[mailto:dox...@li...]On Behalf Of Moshe
Kruger
Sent: 11 July 2001 10:27
To: dox...@li...
Cc: 'di...@st...'
Subject: [Doxygen-users] Changing the standard header


Hi, all!

I wish to plant a Search button in the standard Doxygen header (so
that it will appear on every page of the HTML output), in order to
grant access to users to a non-Doxygen search engine.

Does anybody know how I would do this?

It seems I will have to go into the code and make the change there,
but WHERE in the code?

Thanks

Moshe Kruger
Paradigm Geophysical

[Doxygen-users] RPM for redhat 6.2?

[Ronald v. E. <eij...@iq...>]

SGksDQoNCkFyZSB0aGVyZSBSUE0ncyB0aGF0IGNhbiBiZSB1c2VkIHdpdGggUmVkaGF0IDYuMj8g
SSd2ZSB0cmllZCB0byBpbnN0YWxsIHRoZSBSSCA3LnggUlBNIGJ1dCBpdCBoYXMgbG90cyBvZiBk
ZXBlbmRlbmNpZXMgZm9yIDcueCBycG0ncyB3aGljaCBoYXZlIGRlcGVuZGVuY2llcyBvbiBvdGhl
ciA3LnggcnBtcyBldGMuIGV0Yy4NCg0KSSBhbSBub3cgdXNpbmcgMS4yLjEgKHRoZSBsYXRlc3Qg
cmVsZWFzZSBJIGNvdWxkIGZpbmQgYW4gUlBNIGZvcikgYnV0IEknZCBsaWtlIHRvIG1vdmUgdG8g
dGhlIGxhdGVzdCAmIGdyZWF0ZXN0Lg0KDQpDJ3lhLA0KDQogICAgUm9uYWxkDQo=

[Doxygen-users] C functions

[Kremer M. (PN-SYS/DSA) <Mar...@Te...>]

Hello,
is it possible to list my functions in the compound list?
Or can i create a 'canvas' for all my c functions?
I don't want to use "File Members" for searching my functions.

best regards,

Markus

[Doxygen-users] Changing the standard header

[Moshe K. <Kr...@Pa...>]

Hi, all!
 
I wish to plant a Search button in the standard Doxygen header (so that it
will appear on every page of the HTML output), in order to grant access to
users to a non-Doxygen search engine.
 
Does anybody know how I would do this?
 
It seems I will have to go into the code and make the change there, but
WHERE in the code?
 
Thanks
 
Moshe Kruger
Paradigm Geophysical

[Doxygen-users] Opinion on sorting ToDo and Bug lists?

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

Hi Doxygeners,

Until recently, I was used to add my \todo items to the file level
or to the class level. Now, I am often adding \todo to member
functions. The good thing is that I need not name the method
in the comment.  The bad thing is that the \todo items for members
of one class are spread all over the ToDo documentation page.
This is because the items are sorted by member function 
identifiers without scope (i.e. class) names (even though I am using
HIDE_SCOPE_NAMES       = NO).

Would it be possible to consider the class identifiers be part
of the member identifier when todo, bug or possibly other lists
are generated?

Even better would be to put the \todo from the class level
first and the sorted \todo's related to its members, then
other class and its members, etc.

While it is usually a good idea to put each class to separate files,
it would be probably difficult to embed the file level \todo's into
that order; so, the file level \todo's could be put to the beginning or
to the end of the page.

What is your opinion?

Thanks,

Petr

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

[Doxygen-users] unsubscribe

[<li...@ca...>]

=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
|| Where there is a will there is a way
||--------------------------------------------
|| Hongtao LIAO                               =20
=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

RE: [Doxygen-users] Is it possible to customise the page layout f or class members

[Wagner, V. <VW...@se...>]

The documentation is also used by people who are doing development on (or
with) the documented object(s).
being able to 'copy / paste' is an advantage.

As for having alternate layouts, I have no idea.

-----Original Message-----
From: Joh...@ub... [mailto:Joh...@ub...]
Sent: Monday, 2001 July 09 07:16
To: dox...@li...
Subject: [Doxygen-users] Is it possible to customise the page layout for
class members



Victor,

Sorry I don't see what a compiler has to do with it - this is 
documentation not source code and should be as clear as possible ? In 
any case does doxygen need to be proscriptive on this matter ?

Incidentally the format I would like to use (as shown in the example 
below) is reminicent of pascal decl syntax.

Therefore my question still stands - is it possible to define 
alternative page layouts for class documentation.

JL


















Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


_______________________________________________
Doxygen-users mailing list
Dox...@li...
http://lists.sourceforge.net/lists/listinfo/doxygen-users


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

[Doxygen-users] Is it possible to customise the page layout for class members

[<Joh...@ub...>]

Victor,

Sorry I don't see what a compiler has to do with it - this is 
documentation not source code and should be as clear as possible ? In 
any case does doxygen need to be proscriptive on this matter ?

Incidentally the format I would like to use (as shown in the example 
below) is reminicent of pascal decl syntax.

Therefore my question still stands - is it possible to define 
alternative page layouts for class documentation.

JL









From: "Wagner, Victor" <VW...@se...>
To: "'dox...@li...'"
	 <dox...@li...>
Subject: RE: [Doxygen-users] RE: Is it possible to customise the page 
layo
	ut for class members
Date: Fri, 29 Jun 2001 11:44:29 -0400
Reply-To: dox...@li...

while agreeing that the documentation needs to be useful, I'll point out
that what Doxygen currently outputs is LEGAL syntax for the compiler, 
your
proposal isn't.




--__--__--

From: Joh...@ub...
TO: dox...@li...
Subject: [Doxygen-users] RE: Is it possible to customise the page 
layout for class members



Is it possible to customise the page layout for class members so that 
instead of a table like 

__________________________________
| RETURN VALUE | METHOD(ARGS)     |
|_________________________________|
| RETURN VALUE | METHOD(ARGS)     |
|_________________________________|


we have the alternative format ...

____________________________________
| METHOD  | (ARGS)   | RETURNVALUE |
|__________________________________|
| METHOD  | (ARGS)   | RETURNVALUE |
|__________________________________|

As this is a bit easier on the eye when looking to a particular method.

In my project our type names are pretty long and in the current table 
format the return value column takes up most of the width of the pane, 
leaving the method name and its ares all scrunched up.

I've tried the alternative format shown above in an html editor and it 
is much more readable.

























Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: [Doxygen-users] Function parameter type

[Dean P. <po...@ds...>]

>Hello,
>
>For the function parameters, we can use \param and \retval.
>Is it possible to have a flag to say that the parameter is "in-out"
>The name inout is perhaps not the best one, but I have no idea what to u=
se.
>

We tend to do this in our function documentation (Note: Javadoc syntax):

/**
 * A brief description of the function
 *
 * @param a [in] An input parameter
 * @param b [out] An out parameter
 * @param c [inout] An in-out parameter
 *
 * @return ...
 */

Which formats nicely in doxygen.

Cheers.



-- =

Dean Povey,         | e-m: po...@ds... | JCSI: Java Crypto Toolkit =

Research Scientist  | ph:  +61 7 3864 5120   | uPKI: C PKI toolkit for em=
bedded
Security Unit, DSTC | fax: +61 7 3864 1282   |       systems
Brisbane, Australia | www: security.dstc.com | =