doxygen-users — List for users of doxygen

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Dimitri v. H. <di...@st...>]

On Fri, May 04, 2001 at 03:12:54PM +0200, Patrick Ohly wrote:
> Hi all!
> 
> According to the documentation (and implementation) of
> \ingroup an entity may be put into several different
> groups at once.

Yes, but...

> 
> However, later on in groupdef.cpp:addMemberToGroups()
> this is detected and triggers a warning (groupdef.cpp, line 617):
> 
>   Member ... found in multiple groups.!
>   The member will be put in group ..., and not group ...
> 
> The class MemberDef also allows to set only one GroupDef: 
>     setGroupDef(GroupDef *gd)        { group=gd; }

... members are an exception. Anything else can be in multiple groups.

> Are \ingroup and related mechanisms with more than one
> group per entity deprecated? 

No, but for members there is a slight problem.
Currently, a member is identified by its container and a local label
unique within the container (in html: a file and an anchor). 

Now suppose a member is in two groups and we want to (auto)link to it.
Where should the link go to?

A clean solution would be to link to the natural container of the
member (i.e. for a global function link to the file, for a class
member link to the class), regardless of any artifical group the 
member was put in.

But then what if someone wants its documentation to consist just of
the items that he/she grouped by hand? This would lead to ambigious
links targets in case the member is in multiple groups.

> If you ask me, then I'd be more than happy when each
> entity can only be in one group and I'd volunteer to
> clean up the implementation: 
> 
> - Entry::groups doesn't have to be a list.

It still does for entries that do not represent members.

> - An explicit \ingroup overrides an implicit @{ @}.

That would make sense.

> - A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
>   in another place (e.g. header files uses \defgroup, C files use
>   \addtogroup) - this is currently impossible to implement, but
>   something that I have been missing for quite a while.

Well if it is impossible to implement, then feel free to try
the impossible :-)

Regards,
  Dimitri

[Doxygen-users] RE: Emails from two doxygen mailing lists...

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

I think we're supposed to be using the new one. I believe Dimitri has
already said he will eventually shut down the old one.

Certainly those of us who want to use the digest feature would appreciate
everyone moving to the SourceForge list. :)

Don


-----Original Message-----
From: Catenacci, Onorio [mailto:Ono...@co...]
Sent: Friday, May 04, 2001 1:03 PM
To: dox...@li...; do...@xe...
Subject: Emails from two doxygen mailing lists...


Hi all,

I keep receiving mail from both the old doxygen mailing list and the new
one.  So I'm motivated to ask:

1.) Are we supposed to be using the old mailing list, the new one or does it
matter?

2.) Is the old mailing list scheduled to be shut down at some point in the
future?

--
Onorio Catenacci

RE: [Doxygen-users] Again about translations...

[Alessandro F. <afa...@da...>]

Hi Petr,

...
> As you adviced, the approach like this...
>
> >  QCString trMemberList(const QCString& className)
>
> ...is the right way.

Glad to hear you agree.

...
> In other words, changing the trMemberList() and similar
> to take some arguments will affect the core code, but
> will not break the other maintainers work, nor require from
> them any effort until they decide to update their translator.
> [ This means that the changes will be less painful (for
> Dimitri and others) and the development here can be
> more rapid (because of avoiding dependency on
> the language maintainers). ]

I think changing the core code would be undoubtedly painful, but there
should be a strong motivation in the change too.

> So, the main problem is to find, where the old method
> was called and think deeply whether newly proposed
> method will not create some apparent obstacles in future.

That's the hardest part cause you must grant sufficient flexibility to guard
against every possible future requirement (or at least try to satisfy a
large class of them) without even imagining it.

> Once this is decided, Dimitri (or someone closely
> cooperating with him) can change the interface of
> the decided method and create its appropriate
> default implementation in the adapter class which
> takes advantage of the older method, which
> already gives translated string or substring.

Agreed.

> The maintainters could always look inside a documentation
> whether their implementation is up-to-date or should
> be updated.  (This was not released yet, but the
> perl script for generating the documentation will probably
> be released soon.)

Yes, the latest deep changes in 1.2.7 forced me to a complete revision.

> There already are examples of the changed interface
> in the last CVS releases.  You may have a look at
> trFiles() which was totally replaced by trFile(params).
> There also are good candidates to use exactly the same
> approach, like trAuthors() and trAuthor() -- not done yet.

I'll look closer at it

> Conclusion: Let's start discussing the changes and
> select the first candidates.

I haven't the source handy, but from memory I cite those tr functions which
produce section titles containing entity names (e.g.class or struct names).
More to come.

Alessandro

[Doxygen-users] Emails from two doxygen mailing lists...

[Catenacci, O. <Ono...@co...>]

Hi all,

I keep receiving mail from both the old doxygen mailing list and the new
one.  So I'm motivated to ask:

1.) Are we supposed to be using the old mailing list, the new one or does it
matter?

2.) Is the old mailing list scheduled to be shut down at some point in the
future?

--
Onorio Catenacci

"Assiduous and frequent questioning is indeed the first key to wisdom...for
by doubting we come to inquiry; through inquiring we perceive the truth ..."

--Peter Abelard, "Sic et Non"

[Doxygen-users] Re: Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Guntram B. <be...@Ma...>]

Patrick Ohly wrote:
Patrick Ohly wrote:

>=20
> If you ask me, then I'd be more than happy when each
> entity can only be in one group and I'd volunteer to
> clean up the implementation:

I think it can make sense to have one entity in several
groups, and would therefore strongly advocate that this
will remain an option.
I could however imagine a config option which triggers warnings
if an entity is in several groups, in circumstances where this
is considered an error.

cheers
--guntram


--=20
------------------------------------------------------------------
Dr. Guntram Berti            | voice: ++49 +355 69 37 17
                             | fax  : ++49 +355 69 24 02
LS  Numerische Mathematik &  | be...@ma...
 Wissenschaftliches Rechnen  | http://www.math.tu-cottbus.de/~berti
Institut f=FCr Mathematik      |                     =20
BTU Cottbus                  | R 313,                  O__ =20
Universit=E4tsplatz 3-4        | Lehrgeb=E4ude 1          c/ /'_
D-03044 Cottbus              |                       (*) \(*)=20
------------------------------------------------------------------

[Doxygen-users] enable preprocessing in 1.2.6

[Emanuele O. <oli...@it...>]

Hi,
I generated doxygen documentation with

INLINE_SOURCES         = YES
ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO

and I got inline sources not preprocessed. But I'd like to have them
processed. 
Is it a correct result?
Is it possible to have inline sources pre-processed?

Thanks in advance,

					Emanuele
					Olivetti

[Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Patrick O. <Pat...@pa...>]

Hi all!

According to the documentation (and implementation) of
\ingroup an entity may be put into several different
groups at once.

However, later on in groupdef.cpp:addMemberToGroups()
this is detected and triggers a warning (groupdef.cpp, line 617):

  Member ... found in multiple groups.!
  The member will be put in group ..., and not group ...

The class MemberDef also allows to set only one GroupDef: 
    setGroupDef(GroupDef *gd)        { group=gd; }

Are \ingroup and related mechanisms with more than one
group per entity deprecated? 

If you ask me, then I'd be more than happy when each
entity can only be in one group and I'd volunteer to
clean up the implementation: 

- Entry::groups doesn't have to be a list.
- An explicit \ingroup overrides an implicit @{ @}.
- A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
  in another place (e.g. header files uses \defgroup, C files use
  \addtogroup) - this is currently impossible to implement, but
  something that I have been missing for quite a while.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] Bug in grouping function

[Guntram B. <be...@Ma...>]

Hello doxygeners,

I think I have found a bug in doxygen's grouping output:
Doxygen erroneously puts class member functions of a member group
into another group, defined with @defgroup later on:

Consider the following input:

-------
class A {
public:
  //@{ @name group1
  int f();
  //@}

};

/*! @defgroup g2 Group of functions

 */

/*! @ingroup g2

 */
void fun1();
--------

This leads to the output (group__g2.html):


---------
       Group of functions


Functions

   int=20
      f ()  =20
      ^^^^^^^ NOT IN GROUP g2!
   void=20
      fun1 ()
----------



The error occurs with both doxygen 1.2.7 and 1.2.5,
and also if class A is defined in a separate file.

cheers
--guntram


--=20
------------------------------------------------------------------
Dr. Guntram Berti            | voice: ++49 +355 69 37 17
                             | fax  : ++49 +355 69 24 02
LS  Numerische Mathematik &  | be...@ma...
 Wissenschaftliches Rechnen  | http://www.math.tu-cottbus.de/~berti
Institut f=FCr Mathematik      |                     =20
BTU Cottbus                  | R 313,                  O__ =20
Universit=E4tsplatz 3-4        | Lehrgeb=E4ude 1          c/ /'_
D-03044 Cottbus              |                       (*) \(*)=20
------------------------------------------------------------------

[Doxygen-users] Template problem

[Ren G. <r.g...@ca...>]

Hi !

I have a problem in the following example.
Example:

template <typename XYZ >
class ABC : virtual public XYZ { };

Problem:

I have a class template that is derived from its template parameter "XYZ".
Doxygen makes an error and recognizes the 'XYZ' parameter as a real known
class. That's wrong because 'XYZ' is a wild card - only after the object of
ABC type is created the type of the template will be known.
Therefore it would be better, if Doxygen omits the documentation of the
template parameter 'XYZ '.

MfG
Ren=E9

RE: [Doxygen-users] Again about translations...

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

Hi Alessandro,

Alessandro Falappa wrote...
> [...] italian doesn't have a saxon genitive form.
> [...] Many section titles in the documentation generated 
> by Doxygen adopt the saxon genitive form: in a project
> called Foobar we have "Foobar Documentation" [...]

This is also the Czech language problem.  I had a disussion with
Dimitri earlier.  The conclusion was that there is no
general way how to put translated pieces of text together
so that well looking sentence is produced for all languages.

The only solution is to have trXxxx() with all the 
parameters necessary for composition of a meaningful
sentence.  Then the language maintainer is responsible
for puting the things together -- possibly using results
of other translator methods for generating the pieces.

As you adviced, the approach like this...

>  QCString trMemberList(const QCString& className)

...is the right way.

Fortunately, the new internal mechanism for deriving
national translators was introduced with doxygen 1.2.7.
It uses adapter classes that allow change the interface of 
the Translator class and still preserve the functionality 
of older TranslatorXxxx classes for the Xxxx language.

In other words, changing the trMemberList() and similar
to take some arguments will affect the core code, but 
will not break the other maintainers work, nor require from 
them any effort until they decide to update their translator.
[ This means that the changes will be less painful (for 
Dimitri and others) and the development here can be 
more rapid (because of avoiding dependency on
the language maintainers). ]

The method can even change the name.  Some other
argument can also signalize that the translation should
have some special form like:

 1) for the HTML head title
     "Project, version, class: Member List"

  2) for HTML page heading (i.e. on the page)
     "Member List for class"
  
etc.

So, the main problem is to find, where the old method
was called and think deeply whether newly proposed
method will not create some apparent obstacles in future.

Once this is decided, Dimitri (or someone closely 
cooperating with him) can change the interface of 
the decided method and create its appropriate 
default implementation in the adapter class which
takes advantage of the older method, which
already gives translated string or substring.

The maintainters could always look inside a documentation
whether their implementation is up-to-date or should
be updated.  (This was not released yet, but the 
perl script for generating the documentation will probably
be released soon.)

There already are examples of the changed interface
in the last CVS releases.  You may have a look at
trFiles() which was totally replaced by trFile(params).
There also are good candidates to use exactly the same
approach, like trAuthors() and trAuthor() -- not done yet.

Conclusion: Let's start discussing the changes and 
select the first candidates.

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

[Doxygen-users] Again about translations...

[Alessandro F. <afa...@da...>]

Hi all,
while revising the italian translation I re-noticed a fact: italian doesn't
have a saxon genitive form.

It may be silly to discover an obvious (for me) situation but this fact has
several implications.

Many section titles in the documentation generated by Doxygen adopt the
saxon genitive form: in a project called Foobar we have "Foobar
Documentation" while for a class called Base we have "Base Class
Documentation", "Base Class Member List" and so on.

The equivalent italian translation obtained preserving the above order (name
of the entity then translated string) sounds a bit strange. The correct
order for the italian language is the one which corresponds to
"Documentation of Class Foobar", "List of Members of Class Base" and so on.

A possible but code-breaking solution is to give complete freedom to the
translator by passing an argument to the title translating function
representing the name of the entity, for example:

QCString trMemberList(const QCString& className)

which should return the title of the member list of the class named
<className>.

If, as I suppose, the title is generated calling more than one translation
function (as in those title wich differ by the entity type as in: "Base
Class Member List", "Base Enum Member List", "Base Struct Member List" etc.)
the ideal solution whould be something like the existing function:

QCString trCompoundReference(const char *clName,
                             ClassDef::CompoundType compType,
                             bool isTemplate)

What do other language maintaner and Dimitri think?

Alessandro Falappa

[Doxygen-users] best way to doc inputs to functions that are not params?

[Jake K. <jk...@bi...>]

What's the best way to doc inputs to functions that are not function
parameters?
There is no @in command for describing these interfaces.

i.e.  a function has params, but as input uses a private class member or
other classes as an input.

I am currently used to documenting my code this way:

/**
* function description...
* in:    params, other member inputs m_* that are not params, could be
objects or data,
*        in this case it's a class member m_nMultiplier, but could be
another object.
* out:  (similar to @return), in this case the function return value.
* pre:    object state expectation that this function expects, in this
case:
* pre:    m_nMultiplier is assumed to be initialized to a valid
state/range.
* post:  an object/program state condition that exist after function is
called).  In this case
*        none.
*/
int MyClass::foo( int param1)
{
    return this->m_nMultiplier * param1;
}

Using dxoygen I can convert everything but inputs, what do people use in
this case?
/**
* function description...
* in:  (params, other member inputs m_* that are not params, could be
objects or data)
* @return:    (similar to post, but usually uses for class members)
* @pre    (object state expectation)
* @post  (more of an object state condition).
*/

RE: [Doxygen-users] Mailing list reply address

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

>The MailMan program (which is used by SourceForge) has an option to
>delay incoming mails to prevent auto-reply-flooding. Also, MailMan is
>smart enough to filter a lot of things out that aren't supposed to go
>to the list, including commands like Unsubscribe, and (possibly, I'm
>not sure of this), mails that already have been sent (e.g. auto-respond
>replies).

If the sourceForge mailer is smart enough to deal with auto-responders, then
I agree it is much more convenient to have the reply button send to the
list.

I don't really know much about mailing lists, but I just went to the mailman
home page (www.list.org), and one of the features listed is "Integrated
bounce detection within an extensible framework. Automatic disposition of
bouncing addresses (disable, unsubscribe)". So it sounds like it's taken
care of. Until proven otherwise, I retract my previous suggestion, and
instead suggest we leave it as Dimitri just set it, to reply to the list.

Though you might want to dig around in the list admin options, Dimitri, and
see if there is something that has to be turned on to enable this.

Don

Re: [Doxygen-users] Mailing list reply address

[Jac G. <ja...@ma...>]

>>Last note: xteq mailing list was set up to allow to reply directly to 
the
>>mailing list. doxygen-users ML is set up for replying to the 
originator of
>the
>>message. I believe the ML administrator should set the xteq behavior, 
as it
>>is more convenient.
>
>I realize that it is more convenient, but most mailing lists are set 
to
>reply to the originator for a reason. This avoids the problem we often 
have
>on the xteq list of autoresponders flooding the mailing list when 
someone
>goes out of town and forgets that they are on the mailing list.

The MailMan program (which is used by SourceForge) has an option to 
delay incoming mails to prevent auto-reply-flooding. Also, MailMan is 
smart enough to filter a lot of things out that aren't supposed to go 
to the list, including commands like Unsubscribe, and (possibly, I'm 
not sure of this), mails that already have been sent (e.g. auto-respond 
replies). 

The problem as I recall with the old list was many times that 
autoresponders would reply to the sender, not to the list, so the list 
server couldn't adequately react to the autoresponder (e.g. by 
forwarding the mail to the administrator and putting the recipient on 
hold) because it would never get the mail. So setting the reply-to to 
the list addres wouldn't even work for these brain-dead auto-
responders.

Another issue: many times, people simply reply to mails by clicking the 
reply-button. The reply will be sent to the person who asked so she 
will be happy, but she will also get many replies of other people who 
didn't see the first reply. This is a waste of effort for people who 
regularly reply to questions on the mailing list and don't initiate 
many discussions themselves.

Also, on brain-dead mailing clients (like the one I use, I have to 
admit, even though it was written by my own company), there isn't even 
a reply-to-all or reply-to-sender-not-originator button - you have to 
dig through menus to get to it and of course it's easy to forget to do 
so, especially if you're subscribed to multiple mailing lists (like 
me).

In short: I think the old situation was better and reply-to the mailing 
list address should return.

===Jac

Re: [Doxygen-users] Mailing list reply address

[Dimitri v. H. <di...@st...>]

On Thu, May 03, 2001 at 04:00:17PM -0400, Don McClimans wrote:
> >Last note: xteq mailing list was set up to allow to reply directly to the
> >mailing list. doxygen-users ML is set up for replying to the originator of
> the
> >message. I believe the ML administrator should set the xteq behavior, as it
> >is more convenient.
> 
> I realize that it is more convenient, but most mailing lists are set to
> reply to the originator for a reason. This avoids the problem we often have
> on the xteq list of autoresponders flooding the mailing list when someone
> goes out of town and forgets that they are on the mailing list. I don't know
> if you can change this behavior at SourceForge, but I don't think we
> should - and I urge everyone to not work around this - leave the reply set
> to the originator.

I just changed this the minute before I read your mail :-), but you have a good point. 
Maybe it is better to trade some convenience for less flooding. What do 
you guys think, should reply messages be sent to the poster or to the list?

Regards,
  Dimitri

Re: [Doxygen-users] About Doxygen new language support..

[Dimitri v. H. <di...@st...>]

On Thu, May 03, 2001 at 10:58:01AM +0200, Philippe Lhoste wrote:
> 
> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the originator of the
> message. I believe the ML administrator should set the xteq behavior, as it
> is more convenient.

I've changed mailman's behaviour to mimic xteq's list more closely. Please let
me know if more changes are desired.

Regards,
  Dimitri

[Doxygen-users] Mailing list reply address

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

>Last note: xteq mailing list was set up to allow to reply directly to the
>mailing list. doxygen-users ML is set up for replying to the originator of
the
>message. I believe the ML administrator should set the xteq behavior, as it
>is more convenient.

I realize that it is more convenient, but most mailing lists are set to
reply to the originator for a reason. This avoids the problem we often have
on the xteq list of autoresponders flooding the mailing list when someone
goes out of town and forgets that they are on the mailing list. I don't know
if you can change this behavior at SourceForge, but I don't think we
should - and I urge everyone to not work around this - leave the reply set
to the originator.

RE: [Doxygen-users] About Doxygen new language support..

[Alessandro F. <afa...@da...>]

....
> I may not be the best qualified to answer, but since I have done so lookup
> for a similar question in the Scintilla mailing list, here are my
> conclusions.
> I believe that ansicpg means Ansi Code Page. 1252 is the code page for the
> Ansi character set, ie. the charset that Windows uses for occidental
> (european?) languages.
>
> From the MSDN:
>
> >>>
> The following table shows the correlation of Charset name,
> Charset Value and
> Codepage number:
> Charset Name       Charset Value(hex)  Codepage number
> ------------------------------------------------------
> DEFAULT_CHARSET           1 (x01)
> SYMBOL_CHARSET            2 (x02)
> OEM_CHARSET             255 (xFF)
> ANSI_CHARSET              0 (x00)            1252
> RUSSIAN_CHARSET         204 (xCC)            1251
> EE_CHARSET              238 (xEE)            1250
> GREEK_CHARSET           161 (xA1)            1253
> TURKISH_CHARSET         162 (xA2)            1254
> BALTIC_CHARSET          186 (xBA)            1257
> HEBREW_CHARSET          177 (xB1)            1255
> ARABIC _CHARSET         178 (xB2)            1256
> SHIFTJIS_CHARSET        128 (x80)             932
> HANGEUL_CHARSET         129 (x81)             949
> GB2313_CHARSET          134 (x86)             936
> CHINESEBIG5_CHARSET     136 (x88)             950
> <<<
>
> So this table also explain the charset... BTW, I wonder if fcharset is a
> typo or something I don't know.

Your response answers perfectly to my first question and let me continue in
the translation work!

Anyone about the second question?

> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the
> originator of the
> message. I believe the ML administrator should set the xteq
> behavior, as it
> is more convenient.

I would prefer that behaviour too cause it would make it easier to create a
rule for moving the mailing list messages to a separate mail folder (Yes
seems that Outlook uses the reply to address as the sender address)

Alessandro Falappa

Re: [Doxygen-users] About Doxygen new language support..

[Hendrik S. <do...@HS...>]

"Philippe Lhoste" <Ph...@gm...> wrote:

> [...]
> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the originator of the
> message. I believe the ML administrator should set the xteq behavior, as it
> is more convenient.

  While it might be possible that the ML adds a Reply-To field 
  to every mail (or replaces the one already there), you can 
  always do so by yourself (see my header). 

> Thank you.
> Philippe Lhoste (Paris -- France)

  Schobi

[Doxygen-users] Search button in the tree view

[Holger M. <hmu...@si...>]

Hi doxygen wizards,

can anybody add the the search button within the tree view? I only get it
on the index. I'd like to disable the index, but then I have no search
access. @-)

Many many thanks!
Holger
-- =

=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Holger M=FCller, Dipl.-Ing.                          Tel: +49/7034/92584-77=

Abt. DOTE - Entwicklung                            Fax: +49/7034/92584-99
sitronic GmbH
Robert-Bosch-Str. 9                          eMail: hmu...@si...
D-71116 Gaertringen                          URL: http://www.sitronic.com
=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RE: [Doxygen-users] About Doxygen new language support..

[Philippe L. <Ph...@gm...>]

Alessandro Falappa wrote:
> 	while updating the support for the italian language I came 
> across these
> methods regarding the new RTF language code support, I actually 
> do not know
> their meaning, could someone explain it so I can return something
> meaningful?
> 
>     /*! Used as ansicpg for RTF file */ <<<< what's an ansicpg?
>     virtual QCString trRTFansicp()
>     {
>       return "1252"; <<<< which value should return ?
>     }
> 
>     /*! Used as ansicpg for RTF fcharset */
>     virtual QCString trRTFCharSet()
>     {
>       return "0"; <<<< and here?
>     }

I may not be the best qualified to answer, but since I have done so lookup
for a similar question in the Scintilla mailing list, here are my conclusions.
I believe that ansicpg means Ansi Code Page. 1252 is the code page for the
Ansi character set, ie. the charset that Windows uses for occidental
(european?) languages.

From the MSDN:

>>>
The following table shows the correlation of Charset name, Charset Value and
Codepage number:
Charset Name       Charset Value(hex)  Codepage number
------------------------------------------------------
DEFAULT_CHARSET           1 (x01)
SYMBOL_CHARSET            2 (x02)
OEM_CHARSET             255 (xFF)
ANSI_CHARSET              0 (x00)            1252
RUSSIAN_CHARSET         204 (xCC)            1251
EE_CHARSET              238 (xEE)            1250
GREEK_CHARSET           161 (xA1)            1253
TURKISH_CHARSET         162 (xA2)            1254
BALTIC_CHARSET          186 (xBA)            1257
HEBREW_CHARSET          177 (xB1)            1255
ARABIC _CHARSET         178 (xB2)            1256
SHIFTJIS_CHARSET        128 (x80)             932
HANGEUL_CHARSET         129 (x81)             949
GB2313_CHARSET          134 (x86)             936
CHINESEBIG5_CHARSET     136 (x88)             950
<<<

So this table also explain the charset... BTW, I wonder if fcharset is a
typo or something I don't know.

BTW, I saw an advertisement for VIM, so I will plug (again!) an ad for SciTE
(www.Scintilla.org). This text editor (for Windows and GTK+) have a C/C++
lexer (syntax highlighting) where I added different styles for doc. comments
(/** and /*!) and line doc. comments (/// and //!). I didn't get so far as to
colorize the \tag and @tag, but why not?

I also started to doxyfy (? doxygenify?) the comments of the sources of
Scintilla and SciTE, but it is much a work in progress.

Last note: xteq mailing list was set up to allow to reply directly to the
mailing list. doxygen-users ML is set up for replying to the originator of the
message. I believe the ML administrator should set the xteq behavior, as it
is more convenient.

Thank you.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net

[Doxygen-users] man output: man pages for documented entities

[Patrick O. <Pat...@pa...>]

Hi,

first of all my thanks to Dimitri for including the man
output patches - a few patches less to be added to
my local doxygen source ;-)

I have been at it again, though. This time I have added
the possibility to generate a man page for any entity
(function, enumeration, enumeration value, etc.) that
is documented. This is configurable and defaults to NO,
so that doxygen behaves the same as before. From the new
config file:

# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.

MAN_LINKS              = NO

As usual, patch attached...

Bye, Patrick Ohly
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] About Doxygen new language support..

[Alessandro F. <afa...@da...>]

Hi all,
	while updating the support for the italian language I came across these
methods regarding the new RTF language code support, I actually do not know
their meaning, could someone explain it so I can return something
meaningful?

    /*! Used as ansicpg for RTF file */ <<<< what's an ansicpg?
    virtual QCString trRTFansicp()
    {
      return "1252"; <<<< which value should return ?
    }

    /*! Used as ansicpg for RTF fcharset */
    virtual QCString trRTFCharSet()
    {
      return "0"; <<<< and here?
    }

Second question:
Where is the trGlobal(bool first_capital, bool singular) used?
Is it used as an adjective to construct compound phrases (for example
calling trGlobal and trMember would produce "global member" but not all of
the singular/plural combination make sense)?
Or does it mean global elements of the C++ language (that's those
declaration outside any scope) which appears when one adds a \file comment
in every file?

Thanks
Alessandro Falappa

[Doxygen-users] VIM 5.7: A more complete syntax for doxygen

[Emilio R. <emi...@ma...>]

Hi,
In the attached zip archive you can find a substitute for Vim 5.7 C/C++ syntax definition 
(<VIMDIR>/syntax/c.vim): doxy special comment block 
(/*! ... */, /** ... */, //! ... and //** ...) have a different color than normal comments, 
all tags (\xxx and @xxx) are recognized only if inserted in a special comment block
and someone (todo, note, warning) are highlighted
All lines modified/added to the standard c.vim are marked with a comment (DOXY).

Emilio Riva

RE: [Doxygen-users] Documenting #included files

[Jac G. <ja...@ma...>]

>Thanks for your reply.  If your {} trick works, it might be helpful,
>although I'd rather not split the class tag from the guts of the 
class.

I think it's possible to trick doxygen into it in another way:

#ifdef DOXYGEN
{
#endif

#include "your_file_with_complete_class_definition_here"

#ifdef DOXYGEN
} // balance the braces
#endif

If you want to do it in a legitimate way, you can also use namespaces, 
but I doubt if they are useful in your case because they are probably 
not documented by all compilers.

>Anyway, it sounds like you agree on the usefulness of telling Doxygen 
to
>document #included files.  Do you have any proposed syntax?

The syntax I had in mind was (replace the @ by any other character if 
you want):

//@scaninclude

This command directs doxygen to scan the file that is mentioned in the 
next
#include command.

//@dontscaninclude

This command directs doxygen to NOT scan the file that is mentioned in 
the next #include command, not even if it contains @ifinclude commands 
that would make doxygen scan the code otherwise

//@ifinclude[d] [[operator] value]

This command directs doxygen to scan the code that follows if the 
include-stack's depth corresponds to the specified operator and value. 
<operator> can be < or > or <= or >= or == or !=, if you don't mention 
the operator, == is used. The value is 0 if the file is being scanned 
as base file, 1 if it is included from the base file etc.

I included the patch in which these commands are implemented (and some 
other little goodies :-). It works partly: it will let Doxygen scan the 
included files as it's told to, and it will generate documentation for 
the classes and methods in the included file as it's supposed to. 

However it does NOT work 100%!!!
- doxygen does not generate code fragments for methods in included 
files
- doxygen does not generate hotlinks to code ("Definition in line %d of 
file %s") in included files
- the graphs are not generated correctly for my special case (where 
class definitions are divided over include files, yuck!).

If I would know what to do with the database in scanner.l when the 
preprocessor changes to a different sourcefile, those problems would be 
fixed.
 
By the way, in my opinion, it shouldn't be necessary to patch doxygen 
this way: doxygen should scan the code in the same way that a C/C++ 
preprocessor does. A while ago someone posted a message containing a 
link to a website where someone patched the gcc preprocessor so it 
generates an XML document from which a clever XML parser should be able 
to generate a database that can be used by doxygen.

>  If you don't
>have time to finish your patch for this, I could do it myself.  (I had
>already assumed I'd have to add it if I wanted it.)

Go ahead if you want (just mention me as the original inventor, ok? :-)

I'm sorry, I don't have time to comment this patch right now...

===Jac

cvs diff -u
# irrelevant lines and files truncated
Index: src/config.l
===================================================================
RCS file: /u/kp3softd/cvsroot/src/config.l,v
retrieving revision 1.54
diff -u -r1.54 config.l
--- src/config.l	2001/04/08 19:19:30	1.54
+++ src/config.l	2001/05/02 23:37:44
@@ -14,6 +14,8 @@
 
 %{
 
+//#define YY_USER_ACTION printf("<%d>%s", __LINE__ -2, yytext);
+
 /*
  *	includes
  */
@@ -323,8 +325,9 @@
 
 <*>\0x0d
 <Start,GetString,GetStrList,GetBool,SkipInvalid>"#"	 { 
BEGIN(SkipComment); }
-<Start>[a-z_A-Z][a-z_A-Z0-9]*[ \t]*"="	 { QCString cmd=yytext;
-                                           cmd=cmd.left(cmd.length()-
1).stripWhiteSpace(); 
+<Start>[a-z_A-Z][a-z_A-Z0-9]*[ \t]*("="|"+=")	 { QCString cmd=yytext;
+                                           bool add=(cmd.right(2)=="+=
");
+                                           cmd=cmd.left(cmd.length()-
(1+(int)add)).stripWhiteSpace();
 					   ConfigOption *option = config->get(cmd);
 					   if (option==0) // oops not known
 					   {
@@ -334,6 +337,11 @@
 					   }
 					   else // known tag
 					   {
+					     if (add && option->kind()!=
ConfigOption::O_List)
+					     {
+					       err("Warning: '+=' cannot be used with 
option %s at line %d, file %s; using '='\n",
+					         cmd.data(), yyLineNr, yyFileName.data());
+					     }
 					     switch(option->kind())
 					     {
 					       case ConfigOption::O_Info:
@@ -342,7 +350,7 @@
 						 break;
 					       case ConfigOption::O_List:
 						 l = ((ConfigList *)option)->valueRef();
-					         l->clear();
+					         if (!add) l->clear();
 						 elemStr="";
 					         BEGIN(GetStrList);
 					         break;
@@ -365,39 +373,6 @@
 						 b = ((ConfigBool *)option)->valueRef();
 					         BEGIN(GetBool);
 						 break;
-					     }
-					   }
-					}
-<Start>[a-z_A-Z][a-z_A-Z0-9]*[ \t]*"+="	{ QCString cmd=yytext;
-                                          cmd=cmd.left(cmd.length()-
2).stripWhiteSpace(); 
-					  ConfigOption *option = config->get(cmd);
-					  if (option==0) // oops not known
-					  {
-					    err("Warning: ignoring unsupported tag `%s' at 
line %d, file %s\n",
-						yytext,yyLineNr,yyFileName.data()); 
-					    BEGIN(SkipInvalid);
-					  }
-					  else // known tag
-					  {
-					    switch(option->kind())
-					    {
-					      case ConfigOption::O_Info:
-					        // shouldn't get here!
-					        BEGIN(SkipInvalid);
-						break;
-					      case ConfigOption::O_List:
-					        l = ((ConfigList *)option)->valueRef();
-						elemStr="";
-					        BEGIN(GetStrList);
-					        break;
-					      case ConfigOption::O_Enum:
-					      case ConfigOption::O_String:
-					      case ConfigOption::O_Int:
-					      case ConfigOption::O_Bool:
-					        err("Warning: operator += not supported for 
`%s'. Ignoring line at line %d, file %s\n",
-						    yytext,yyLineNr,yyFileName.data()); 
-					        BEGIN(SkipInvalid);
-						break;
 					     }
 					   }
 					}
Index: src/doxygen.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/doxygen.cpp,v
retrieving revision 1.66
diff -u -r1.66 doxygen.cpp
--- src/doxygen.cpp	2001/04/30 17:28:32	1.66
+++ src/doxygen.cpp	2001/05/02 23:37:45
@@ -2818,9 +2818,9 @@
       {
         warn(
              root->fileName,root->startLine,
-             "Warning: member %s belongs to two different groups. The 
second "
-             "one found here will be ignored.",
-             md->name().data()
+             "Warning: member %s belongs to two different groups.\n"
+             "The one that will be used is at %s:%d",
+             md->name().data(), md->getDefFileName().data(), md->
getDefLine()
             );
       }
     }
@@ -5493,16 +5493,6 @@
   {
     QCString fileName=*s;
 
-    int fileNameSize=fileName.length();
-
-    // add begin filename marker
-    output.addChar(0x06);
-    // copy filename
-    output.addArray(fileName.data(),fileNameSize);
-    
-    // add end filename marker
-    output.addChar(0x06);
-    output.addChar('\n');
     if (Config_getBool("ENABLE_PREPROCESSING"))
     {
       msg("Preprocessing %s...\n",s->data());
@@ -5510,6 +5500,18 @@
     }
     else
     {
+      // add begin filename marker
+      output.addChar(0x06);
+      // copy filename
+      output.addArray(fileName.data(),fileName.length());
+
+      // add line number
+      output.addChar(0x06);
+      output.addChar('1');
+      
+      // add end filename marker
+      output.addChar(0x06);
+
       msg("Reading %s...\n",s->data());
       copyAndFilterFile(fileName,output);
     }
Index: src/message.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/message.cpp,v
retrieving revision 1.25
diff -u -r1.25 message.cpp
--- src/message.cpp	2001/04/22 19:01:52	1.25
+++ src/message.cpp	2001/05/02 23:37:45
@@ -142,7 +142,7 @@
 {
   if (Config_getBool("WARN_IF_UNDOCUMENTED"))
   {
-    if (file==0) file="<unknwon>";
+    if (file==0) file="<unknown>";
     char text[4096];
     va_list args;
     va_start(args, fmt);
Index: src/pre.l
===================================================================
RCS file: /u/kp3softd/cvsroot/src/pre.l,v
retrieving revision 1.39
diff -u -r1.39 pre.l
--- src/pre.l	2001/04/08 19:19:31	1.39
+++ src/pre.l	2001/05/02 23:37:46
@@ -17,6 +17,8 @@
 
 %{
 
+//#define YY_USER_ACTION printf("<%d>%s", __LINE__ -2, yytext);
+
 /*
  *	includes
  */
@@ -53,15 +55,71 @@
 
 #define YY_NEVER_INTERACTIVE 1
   
-
+typedef enum
+{
+  ScanIncNA,	// we're not including (this is the base file)
+  ScanIncNone,  // no commands active
+  ScanIncYes,	// scaninclude given
+  ScanIncNo	// dontscaninclude given
+} ScanInclude;
+
+typedef enum
+{
+  IfIncNone,	// no ifinclude given
+  IfIncEQ,	// ifinclude == or =
+  IfIncNE,	// ifinclude != or <>
+  IfIncLT,	// ifinclude <
+  IfIncLE,	// ifinclude <=
+  IfIncGT,	// ifinclude >
+  IfIncGE	// ifinclude >=
+} IfIncComp;
+
+typedef enum
+{
+  PreNone,		// no preprocessor command found
+  PreScanInclude,	// scaninclude found
+  PreDontScanInclude,	// dontscaninclude found
+  PreIfInclude		// if[not]include[d]/endifinclude[d] found
+} PreProcessorCmd;
+ 
 struct FileState
 {
-  int lineNr;
-  FILE *filePtr;
-  YY_BUFFER_STATE bufState;
-  QCString fileName;
+  int                   lineNr;
+  FILE                 *filePtr;
+  YY_BUFFER_STATE       bufState;
+  QCString              fileName;
+  QCString              bareFileName;
+  int                   pathListIndex;
+  ScanInclude           parentScanInclude;
+  uint                  ifIncDepth;
+  IfIncComp             ifIncComp;
 };  
 
+// Extended version of QStack, which includes a next() operation.
+template<class type> class WalkableStack : private QGList
+{
+public:
+    WalkableStack()				{}
+    WalkableStack( const WalkableStack<type> &s ) : QGList(s) {}
+   ~WalkableStack()				{ clear(); }
+    WalkableStack<type> &operator=(const WalkableStack<type> &s)
+			{ return (WalkableStack<type>&)QGList::operator=(s); }
+    bool  autoDelete() const		{ return QCollection::autoDelete(); 
}
+    void  setAutoDelete( bool del )	{ 
QCollection::setAutoDelete(del); }
+    uint  count()   const		{ return QGList::count(); }
+    bool  isEmpty() const		{ return QGList::count() == 0; }
+    void  push( const type *d )		{ QGList::insertAt(0,Item(d)); 
}
+    type *pop()				{ return (type *)QGList::takeFirst(); }
+    bool  remove()			{ return QGList::removeFirst(); }
+    void  clear()			{ QGList::clear(); }
+    type *top()	    const		{ return (type *)QGList::cfirst(); 
}
+	  operator type *() const	{ return (type *)QGList::cfirst(); }
+    type *current() const		{ return (type *)QGList::cfirst(); }
+    type *next() 			{ return (type *)QGList::next(); }
+private:
+    void  deleteItem( Item d ) { if ( del_item ) delete (type *)d; }
+};
+
 /* -----------------------------------------------------------------
  *
  *	scanner's state
@@ -69,10 +127,12 @@
 
 static int                g_yyLineNr   = 1;
 static QCString           g_yyFileName;
+static QCString           g_bareFileName;
 static FileDef           *g_yyFileDef;
 static int                g_ifcount    = 0;
 static QStrList          *g_pathList = 0;  
-static QStack<FileState>  g_includeStack;
+static WalkableStack<FileState>  g_includeStack;
+static int                g_currentPathListIndex = -1;
 static QDict<int>        *g_argDict;
 static int                g_defArgs = -1;
 static QCString           g_defName;
@@ -83,6 +143,7 @@
 static int                g_level;
 static int                g_lastCContext;
 static int                g_lastCPPContext;
+static int		  g_nextCommentContext;
 static QArray<int>        g_levelGuard;
 static BufStr            *g_outputBuf;
 static int                g_roundCount;
@@ -92,10 +153,18 @@
 static int                g_findDefArgContext;
 static QCString           g_lastGuardName;
 static QCString           g_incName;
+static bool               g_incNext;
 static QCString           g_guardExpr;
 static int                g_curlyCount;
 static bool               g_nospaces; // add extra spaces during macro 
expansion
-
+static PreProcessorCmd    g_doxyCmd;
+static ScanInclude        g_parentScanInclude;
+static ScanInclude	  g_scanInclude;
+static IfIncComp	  g_ifIncComp;
+static uint		  g_ifIncDepth;
+static bool               g_scanEnabledCache=true;
+static bool               g_scanEnabledCacheChanged=true;
+static bool               g_fileNeedsMark=false;
 static bool               g_macroExpansion; // from the configuration
 static bool               g_expandOnlyPredef; // from the 
configuration
 
@@ -103,8 +172,21 @@
 static void setFileName(const char *name)
 {
   bool ambig;
+  Debug::print(Debug::Preprocessor,0,"opening %s\n",name);
   g_yyFileName=name;
   g_yyFileDef=findFileDef(Doxygen::inputNameDict,g_yyFileName,ambig);
+  g_fileNeedsMark=true;
+}
+
+static void outputFileMarker(void)
+{
+  g_outputBuf->addChar('\x06');
+  g_outputBuf->addArray(g_yyFileName.data(),g_yyFileName.length());
+  g_outputBuf->addChar('\x06');
+  QCString lineno;lineno.setNum(g_yyLineNr);
+  g_outputBuf->addArray(lineno.data(),lineno.length());
+  g_outputBuf->addChar('\x06');
+  g_fileNeedsMark=false;
 }
 
 static void incrLevel()
@@ -161,7 +243,7 @@
   return 0;
 }
 
-static FILE *checkAndOpenFile(const QCString &absName)
+static FILE *checkAndOpenFile(const QCString &absName, const QCString 
&bareName, int pathListIndex)
 {
   FILE *f = 0;
   QFileInfo fi(absName);
@@ -178,20 +260,30 @@
       f=fopen(absName,"r");
       if (!f) err("Error: could not open file %s for reading\
n",absName.data());
     }
+    if (f)
+    {
+      setFileName(absName);
+      g_yyLineNr=1;
+      g_parentScanInclude=g_scanInclude;
+      g_scanInclude=ScanIncNone;
+      g_ifIncComp=IfIncNone;
+      g_scanEnabledCacheChanged=true;
+      g_bareFileName=bareName;
+      g_currentPathListIndex=pathListIndex;
+      yy_switch_to_buffer(yy_create_buffer((preYYin=f), YY_BUF_SIZE));
+    }
   }
   return f;
 }
 
-static FILE *findFile(const char *fileName,bool localInclude)
+static FILE *findFile(const QCString &fileName,bool localInclude)
 {
   if (localInclude && g_yyFileDef)
   {
-    QCString absName = g_yyFileDef->getPath()+"/"+fileName;
-    FILE *f = checkAndOpenFile(absName);
+    QCString absName = g_yyFileDef->getPath()+fileName;
+    FILE *f = checkAndOpenFile(absName, fileName, 
g_currentPathListIndex);
     if (f)
     {
-      setFileName(absName);
-      g_yyLineNr=1;
       return f;
     }
   }
@@ -200,17 +292,30 @@
     return 0;
   }
   char *s=g_pathList->first();
+
+  int foundPathListIndex=0;
+  int startingIndex=0;
+  if (g_incNext && !strcmp(g_bareFileName.data(), fileName.data()))
+  {
+    // Get the current include-path index and search from there.
+    // Note that for the base filename, the current path list index is
+    // set to -1, so the search starts at 0.
+    startingIndex=g_currentPathListIndex+1;
+  }
+  
   while (s)
   {
-    QCString absName = (QCString)s+"/"+fileName;
-    FILE *f = checkAndOpenFile(absName);
-    if (f)
+    if (foundPathListIndex>=startingIndex)
     {
-      setFileName(absName);
-      g_yyLineNr=1;
-      return f;
-    }
+      QCString absName = (QCString)s+"/"+fileName;
+      FILE *f = checkAndOpenFile(absName, fileName, 
foundPathListIndex);
+      if (f)
+      {
+        return f;
+      }
 
+    }
+    foundPathListIndex++;
     s=g_pathList->next();
   } 
   return 0;
@@ -880,19 +985,123 @@
   //if ((d=defineDict[g_defName])==0) 
defineDict.insert(g_defName,newDefine()); 
 }
 
+static inline bool scanEnabled(void)
+{
+  if (g_scanEnabledCacheChanged)
+  {
+    // by defrault, scanning is enabled
+    bool b=true;
+
+    // check for dontscaninclude override
+    if (g_parentScanInclude==ScanIncNo)
+    {
+      // parent disallows scanning
+      b=false;
+    }
+    else
+    {
+      // we're not in an include or the parent allows/mandates 
scanning
+      uint depth=g_includeStack.count();
+      
+      // check for ifinclude override
+      switch (g_ifIncComp)
+      {
+      case IfIncNone:
+        // No ifinclude present. Check if parent mandates scanning
+        b=((depth==0) ||
+           (g_parentScanInclude==ScanIncYes) ||
+           ((depth!=0) && (g_curlyCount>0)));
+        break;
+      case IfIncEQ:
+        // include level must be equal to given number
+        b=(depth==g_ifIncDepth);
+        break;
+      case IfIncNE:
+        // include level must be unequal to given number
+        b=(depth!=g_ifIncDepth);
+        break;
+      case IfIncLT:
+        // include level must be less than given number
+        b=(depth<g_ifIncDepth);
+        break;
+      case IfIncLE:
+        // include level must be less or equal to given number
+        b=(depth<g_ifIncDepth);
+        break;
+      case IfIncGT:
+        // include level must be greater than given number
+        b=(depth>g_ifIncDepth);
+        break;
+      case IfIncGE:
+        // include level must be greater or equal to given number
+        b=(depth>=g_ifIncDepth);
+        break;
+      }
+    }
+    
+    // copy local to global
+    g_scanEnabledCache=b;
+    
+    // if scanning is enabled, mark the current position
+    if (g_scanEnabledCache && g_fileNeedsMark)
+    {
+      outputFileMarker();
+    }
+    g_scanEnabledCacheChanged=false;
+  }
+  return g_scanEnabledCache;
+}
+
 static inline void outputChar(char c)
 {
-  if (g_includeStack.isEmpty() || g_curlyCount>0) g_outputBuf->
addChar(c);
+  if (scanEnabled()) g_outputBuf->addChar(c);
 } 
 
 static inline void outputArray(const char *a,int len)
 {
-  if (g_includeStack.isEmpty() || g_curlyCount>0) g_outputBuf->
addArray(a,len);
+  if (scanEnabled()) g_outputBuf->addArray(a,len);
 }
 
+/*! this is called at the end of each source line and at the end of 
each
+ * C comment, to execute any preprocessor commands that were found.
+ * Note: We need to postpone processing the command until after the
+ * comment ends, because if scanning is enable or disabled by the 
command,
+ * the scanner would otherwise end up with an unclosed or unopened 
comment.
+ * We CAN postpone processing until the end of the comment because
+ * preprocessor commands need to be right after the beginning of
+ * the comment, so there can never be more than one command per 
comment.
+ */
+static void execPreProcCmd(void)
+{
+  switch (g_doxyCmd)
+  {
+  case PreScanInclude:
+    g_scanInclude=ScanIncYes;
+    g_scanEnabledCacheChanged=true;
+    break;
+  case PreDontScanInclude:
+    g_scanInclude=ScanIncNo;
+    g_scanEnabledCacheChanged=true;
+    break;
+  case PreIfInclude:
+    g_scanEnabledCacheChanged=true;
+    break;
+  case PreNone:
+  default:
+    ; // Nothing to do
+  }
+  
+  // reset the command, just in case
+  g_doxyCmd=PreNone;
+}
+
 static void readIncludeFile(const QCString &inc)
 {
-  if (!Config_getBool("SEARCH_INCLUDES")) return; // do not read 
include files
+  if (!Config_getBool("SEARCH_INCLUDES"))
+  {
+    Debug::print(Debug::Preprocessor,0,"SEARCH_INCLUDES is false; not 
including %s\n",inc.data());
+    return; // do not read include files
+  }
   uint i=0;
   
   // find the start of the include file name
@@ -913,16 +1122,26 @@
     QCString incFileName=inc.mid(s,i-s).stripWhiteSpace(); 
 
     FILE *f;
-    QCString oldFileName = g_yyFileName.copy();
     FileDef *oldFileDef  = g_yyFileDef;
-    int oldLineNr        = g_yyLineNr;
+
+    // store the state of the old file 
+    FileState *fs=new FileState;
+    fs->bufState=YY_CURRENT_BUFFER;
+    fs->lineNr=g_yyLineNr;
+    fs->fileName=g_yyFileName.copy();
+    fs->bareFileName=g_bareFileName;
+    fs->pathListIndex=g_currentPathListIndex;
+    fs->parentScanInclude=g_parentScanInclude;
+    fs->ifIncDepth=g_ifIncDepth;
+    fs->ifIncComp=g_ifIncComp;
+
     //printf("Searching for `%s'\n",incFileName.data());
     if ((f=findFile(incFileName,localInclude))) // see if the include 
file can be found
     {
       if (Debug::isFlagSet(Debug::Preprocessor))
       {
-        for (i=0;i<g_includeStack.count();i++) msg("  ");
-        msg("#include %s: parsing...\n",incFileName.data());
+        for (i=0;i<=g_includeStack.count();i++) msg("  ");
+        msg("#include%s %s: parsing...\n", g_incNext?"_next":"", 
incFileName.data());
       }
       if (oldFileDef) 
       {
@@ -934,26 +1153,19 @@
   	  g_yyFileDef->addIncludedByDependency(oldFileDef,oldFileDef->
name(),localInclude);
         }
       }
-      FileState *fs=new FileState;
-      fs->bufState=YY_CURRENT_BUFFER;
-      fs->lineNr=oldLineNr;
-      fs->fileName=oldFileName;
       fs->filePtr=f;
       // push the state on the stack
       g_includeStack.push(fs);
-      // set the scanner to the include file
 
       // TODO: Enable this to deal with file changes due to 
       // #include's within { .. } blocks
       //QCString lineStr;
       //lineStr.sprintf("# 1 \"%s\" 1\n",g_yyFileName.data());
       //outputArray(lineStr.data(),lineStr.length());
-      
-      preYYin=f;
-      yy_switch_to_buffer(yy_create_buffer(preYYin, YY_BUF_SIZE));
     } 
     else
     {
+      delete fs; // delete unused data
       if (oldFileDef) 
       {
 	bool ambig;
@@ -966,9 +1178,17 @@
   	  fd->addIncludedByDependency(oldFileDef,oldFileDef->
name(),localInclude);
         }
       }
-      if (Debug::isFlagSet(Debug::Preprocessor))
-      {
-        msg("#include %s: not found! skipping...\
n",incFileName.data());
+      // failing #include_next's are apparently not reported by gcc,
+      // so we won't complain about failed #include_next's either
+      if (!g_incNext)
+      {
+        warn(g_yyFileName.data(), g_yyLineNr, "#include %s: not found! 
skipping...", incFileName.data());
+        FileState *fs=g_includeStack.top();
+        while (fs)
+        {
+          warn_cont("  included from: %s:%d\n", fs->fileName.data(), 
fs->lineNr);
+          fs=g_includeStack.next();
+        }
         //printf("Error: include file %s not found\n",yytext);
       }
     }
@@ -977,11 +1197,14 @@
 
 /* ----------------------------------------------------------------- *
/
 
+#define DO_LINEFEED do { outputChar('\n'); g_yyLineNr++; 
execPreProcCmd(); } while(0)
+
 %}
 
 ID	[a-z_A-Z][a-z_A-Z0-9]*
 B       [ \t]
 BN	[ \t\r\n]
+CMD	[@]
 
 %option noyywrap
 
@@ -999,6 +1222,8 @@
 %x      SkipCPPBlock
 %x      Ifdef
 %x      Ifndef
+%x	DoxyCommand
+%x	IfIncludeParm
 %x	SkipCComment
 %x	SkipCPPComment
 %x	RemoveCComment
@@ -1044,12 +1269,18 @@
 
 <CopyLine>"{"				{ // count brackets inside the main file
   					  if (g_includeStack.isEmpty()) 
+  					  {
 					    g_curlyCount++;
+					    g_scanEnabledCacheChanged=true;
+					  }
 					  outputChar(*yytext);
   					}
 <CopyLine>"}"				{ // count brackets inside the main file
   					  if (g_includeStack.isEmpty()) 
+  					  {
 					    g_curlyCount--;
+					    g_scanEnabledCacheChanged=true;
+					  }
 					  outputChar(*yytext);
 					  // This should hold otherwise the preprocessor is 
confused
 					  //ASSERT(g_curlyCount>=0); 
@@ -1132,9 +1363,8 @@
   					  outputChar(*yytext);
   					}
 <CopyLine>\n				{
-  					  outputChar('\n');
+  					  DO_LINEFEED;
 					  BEGIN(Start);
-					  g_yyLineNr++;
   					}
 <FindDefineArgs>"("			{
   					  g_defArgsStr+='(';
@@ -1170,8 +1400,7 @@
   					  BEGIN(ReadString);
   					}
 <FindDefineArgs>\n			{
-  					  g_yyLineNr++;
-					  outputChar('\n');
+  					  DO_LINEFEED;
   					}
 <FindDefineArgs>"@"			{
   					  g_defArgsStr+="@@";
@@ -1192,7 +1421,20 @@
 <ReadString>.				{
   					  g_defArgsStr+=*yytext;
   					}
+<Command>"include_next"{B}+/{ID}	{
+                                          g_incNext=true;
+  					  if (g_macroExpansion) 
+					    BEGIN(IncludeID);
+  					}
+<Command>"include_next"{B}*[<"]		{ 
+					  char c[2];
+					  c[0]=yytext[yyleng-1];c[1]='\0';
+					  g_incName=c;
+					  g_incNext=true;
+  					  BEGIN(Include); 
+					}
 <Command>"include"{B}+/{ID}		{
+					  g_incNext=false;
   					  if (g_macroExpansion) 
 					    BEGIN(IncludeID);
   					}
@@ -1200,6 +1442,7 @@
 					  char c[2];
 					  c[0]=yytext[yyleng-1];c[1]='\0';
 					  g_incName=c;
+					  g_incNext=false;
   					  BEGIN(Include); 
 					}
 <Command>"define"{B}+			{ 
@@ -1272,16 +1515,15 @@
   					  decrLevel();
   					}
 <Command,IgnoreLine>\n			{
-  					  outputChar('\n');
+
+  					  DO_LINEFEED;
   					  BEGIN(Start);
-					  g_yyLineNr++;
   					}
 <Command>{ID}				{ // unknown directive
 					  BEGIN(IgnoreLine);
 					}
 <IgnoreLine>\\[\r]?\n			{
-  					  outputChar('\n');
-					  g_yyLineNr++;
+  					  DO_LINEFEED;
 					}
 <IgnoreLine>.
 <Command>.
@@ -1295,9 +1537,8 @@
 					  BEGIN(Start);
   					}
 <Guard>\\[\r]?\n			{
-  					  outputChar('\n');
+  					  DO_LINEFEED;
   					  g_guardExpr+=' ';
-					  g_yyLineNr++;
   					}
 <Guard>"defined"/{B}*"("		{
     					  BEGIN(DefinedExpr2);
@@ -1307,8 +1548,7 @@
     					}
 <Guard>.				{ g_guardExpr+=*yytext; }
 <Guard>\n				{
-  					  outputChar('\n');
-					  g_yyLineNr++;
+  					  DO_LINEFEED;
   					  //printf("Guard: `%s'\n",
 					  //    g_guardExpr.data());
 					  bool guard=computeExpression(g_guardExpr);
@@ -1324,7 +1564,7 @@
 					    BEGIN(SkipCPPBlock);
 					  }
   					}
-<DefinedExpr1,DefinedExpr2>\\\n		{ g_yyLineNr++; outputChar('\
n'); }
+<DefinedExpr1,DefinedExpr2>\\\n		{ DO_LINEFEED; }
 <DefinedExpr1>{ID}			{
   					  if (isDefined(yytext))
 					    g_guardExpr+=" 1L ";
@@ -1389,8 +1629,7 @@
 					  }
 					}
 <SkipCommand>\n				{ 
-  					  outputChar('\n');
-  					  g_yyLineNr++; 
+  					  DO_LINEFEED;
 					  BEGIN(SkipCPPBlock);
 					}
 <SkipCommand>{ID}			{ // unknown directive 
@@ -1408,8 +1647,7 @@
   					  BEGIN(RemoveCComment);
   					}
 <SkipLine>\n				{
-  					  outputChar('\n');
-					  g_yyLineNr++;  
+  					  DO_LINEFEED;
 					  BEGIN(SkipCPPBlock);
 					}
 <IncludeID>{ID}{B}*/"("			{
@@ -1530,16 +1768,99 @@
 					  g_defText+=' ';
 					  g_defLitText+=' ';
 					  g_lastCContext=YY_START;
-  					  BEGIN(SkipCComment);
+					  g_nextCommentContext=SkipCComment;
+  					  BEGIN(DoxyCommand);
   					}
 <DefineText>"//"			{
   				          outputChar('/');outputChar('/');
   					  g_lastCPPContext=YY_START;
 					  g_defLitText+=' ';
-  					  BEGIN(SkipCPPComment);
+					  g_nextCommentContext=SkipCPPComment;
+  					  BEGIN(DoxyCommand);
   					}
+<DoxyCommand>{B}*{CMD}"scaninclude"     {
+                                          g_doxyCmd=PreScanInclude;
+                                          BEGIN(g_nextCommentContext);
+                                        }
+<DoxyCommand>{B}*{CMD}"dontscaninclude" {
+                                          g_doxyCmd=
PreDontScanInclude;
+                                          BEGIN(g_nextCommentContext);
+                                        }
+<DoxyCommand>{B}*{CMD}"ifinclude"[d]{B}* {
+                                          g_doxyCmd=PreIfInclude;
+                                          g_ifIncDepth=0;
+                                          g_ifIncComp=IfIncGT;
+                                          BEGIN(IfIncludeParm);
+                                        }
+<IfIncludeParm>("<="|"<"|"="|"=="|"!="|"<>"|">"|">="){B}*/[0-9] {
+					  switch (yytext[0])
+					  {
+					  case '<':
+					    switch (yytext[1])
+					    {
+					    case '=':
+					      g_ifIncComp=IfIncLE;
+					      break;
+					    case '>':
+					      g_ifIncComp=IfIncNE;
+					      break;
+					    default:
+					      g_ifIncComp=IfIncLT;
+					    }
+					    break;
+					  case '=': // '=' or '=='
+					    g_ifIncComp=IfIncEQ;
+					    break;
+					  case '!':
+					    g_ifIncComp=IfIncNE;
+					    break;
+					  case '>':
+					    switch (yytext[1])
+					    {
+					    case '=':
+					      g_ifIncComp=IfIncGE;
+					      break;
+					    default:
+					      g_ifIncComp=IfIncGT;
+					    }
+					    break;
+					  default:
+					    ; // never happens
+					  }
+					}
+<IfIncludeParm>[0-9]+			{
+					  g_ifIncDepth=0;
+					  int i=0;
+					  while (yytext[i])
+					  {
+					    g_ifIncDepth=g_ifIncDepth*10+(yytext[i]-'0');
+					    i++;
+					  }
+					  BEGIN(g_nextCommentContext);
+					}
+<IfIncludeParm>"//"|"/*"|.|\n		{
+					  yyless(0);
+					  BEGIN(g_nextCommentContext);
+					}
+<DoxyCommand>{B}*{CMD}"ifnotinclude"[d] {
+                                          g_doxyCmd=PreIfInclude;
+                                          g_ifIncDepth=0;
+                                          g_ifIncComp=IfIncEQ;
+                                          BEGIN(g_nextCommentContext);
+                                        }
+<DoxyCommand>{B}*{CMD}"endifinclude"[d] {
+                                          g_doxyCmd=PreIfInclude;
+                                          g_ifIncComp=IfIncNone;
+                                          BEGIN(g_nextCommentContext);
+                                        }
+<DoxyCommand>"//"|"/*"|.|\n             {
+                                          g_doxyCmd=PreNone;
+                                          yyless(0);
+                                          BEGIN(g_nextCommentContext);
+   					}
 <SkipCComment>"*/"			{
   					  outputChar('*');outputChar('/');
+  					  execPreProcCmd();
   					  BEGIN(g_lastCContext);  
   					}
 <SkipCComment>"//"			{
@@ -1552,8 +1873,7 @@
   					  outputArray(yytext,yyleng);
   					}
 <SkipCComment>\n			{ 
-  					  g_yyLineNr++;
-  					  outputChar('\n');
+  					  DO_LINEFEED;
   					}
 <SkipCComment>.				{
   					  outputChar(*yytext);
@@ -1562,7 +1882,7 @@
 <RemoveCComment>"//"			
 <RemoveCComment>"/*"
 <RemoveCComment>[^*\n]+
-<RemoveCComment>\n			{ g_yyLineNr++; outputChar('\n'); }
+<RemoveCComment>\n			{ DO_LINEFEED; }
 <RemoveCComment>.			
 <SkipCPPComment,RemoveCPPComment>\n	{
   					  unput(*yytext);
@@ -1623,12 +1943,11 @@
   					}
 <DefineText>\\[\r]?\n			{ 
 					  g_defLitText+=yytext;
-  					  outputChar('\n');
-  					  g_defText += ' '; g_yyLineNr++; 
+  					  DO_LINEFEED;
+  					  g_defText += ' ';
 					}
 <DefineText>\n				{
 					  g_defLitText+=yytext;
-  					  outputChar('\n');
   					  Define *def=0;
 					  //printf("Define name=`%s' text=`%s' litTexti=
`%s'\n",g_defName.data(),g_defText.data(),g_defLitText.data());
 					  if (g_includeStack.isEmpty() || g_curlyCount>0) 
@@ -1660,7 +1979,7 @@
 					    }
 					  }
 					  delete g_argDict; g_argDict=0;
-					  g_yyLineNr++;
+					  DO_LINEFEED;
 					  g_lastGuardName.resize(0);
 					  BEGIN(Start);
   					}
@@ -1712,6 +2031,13 @@
 					    yy_delete_buffer( oldBuf );
 					    g_yyLineNr=fs->lineNr;
 					    setFileName(fs->fileName.copy());
+					    g_currentPathListIndex=fs->pathListIndex;
+					    g_scanInclude=ScanIncNone; // Reset, don't use 
fs->scanInclude!
+					    g_parentScanInclude=fs->parentScanInclude;
+					    g_ifIncDepth=fs->ifIncDepth;
+					    g_ifIncComp=fs->ifIncComp;
+                                            g_scanEnabledCacheChanged=
true;
+                                            g_bareFileName=fs->
bareFileName;
 					    //printf("######## FileName %s\
n",g_yyFileName.data());
 					    
                                             // TODO: Enable this to 
deal with file changes due to 
@@ -1728,16 +2054,17 @@
 <*>"/*"					{
 					  outputChar('/');outputChar('*');
   					  g_lastCContext=YY_START;
-					  BEGIN(SkipCComment);
+  					  g_nextCommentContext=SkipCComment;
+					  BEGIN(DoxyCommand);
   					}
 <*>"//"					{
 					  outputChar('/');outputChar('/');
   					  g_lastCPPContext=YY_START;
-					  BEGIN(SkipCPPComment);
+  					  g_nextCommentContext=SkipCPPComment;
+					  BEGIN(DoxyCommand);
 					}
 <*>\n					{ 
-  					  outputChar('\n');
-  					  g_yyLineNr++; 
+  					  DO_LINEFEED;
 					}
 <*>.				        {
   					  outputChar(*yytext);
@@ -1971,10 +2298,17 @@
       return;
     }
   }
-  g_yyLineNr = 1;
   g_level    = 0;
   g_ifcount  = 0;
+  g_currentPathListIndex=-1;
+  g_parentScanInclude=ScanIncNA;
+  g_scanInclude=ScanIncNone;
+  g_ifIncComp=IfIncNone;
+  g_scanEnabledCacheChanged=true;
+  g_yyLineNr = 0; // indicate to scanner that this is a base file
   setFileName(fileName);
+  outputFileMarker();
+  g_yyLineNr = 1;
   BEGIN( Start );
   
   g_lastGuardName.resize(0);
@@ -1993,10 +2327,19 @@
     msg("Preprocessor output (size: %d bytes):\n",newPos-orgPos);
     int line=1;
     msg("---------\n00001 ");
+    int markercount=0;
     while (orgPos<newPos) 
     {
+      if (*orgPos==6)
+      {
+        if (++markercount==3)
+          markercount=0;
+      }
+      else if (markercount==0)
+      {
       putchar(*orgPos);
       if (*orgPos=='\n') printf("%05d ",++line);
+      }
       orgPos++;
     }
     msg("\n---------\n");
Index: src/scanner.l
===================================================================
RCS file: /u/kp3softd/cvsroot/src/scanner.l,v
retrieving revision 1.62
diff -u -r1.62 scanner.l
--- src/scanner.l	2001/04/30 17:28:33	1.62
+++ src/scanner.l	2001/05/02 23:37:47
@@ -17,6 +17,8 @@
   
 %{
 
+//#define YY_USER_ACTION printf("<%d>%s", __LINE__ -2, yytext);
+
 /*
  *	includes
  */
@@ -101,6 +103,7 @@
 static int              anonCount    = 0 ;        
 static char		yyFileName[4096] ;
 static int              lastMemberGroupLine;
+static QCString		lastMemberGroupFile;
 static MethodTypes 	mtype;
 static bool    		gstat;
 static bool             removeSlashes;
@@ -532,31 +535,32 @@
 
 %%
 
-<*>\x06[^\x06]*\x06			{ // new file
-  					  if (memberGroupId!=NOGROUP)
-					  {
-					    warn(yyFileName,yyLineNr,"Warning: Missing //
@}");
-					    memberGroupId=NOGROUP;
-					  }
-  					  yyLineNr= 0 ; // there is always an extra newline 
at the start of the file
+<*>\x06[^\x06]*\x06[0-9]+\x06		{ // new file
 					  int i; 
 					  for( i = 0 ; yytext[i+1] != 6 ; i++ )
 					    yyFileName[i] = yytext[i+1] ;
 					  yyFileName[i] = 0 ;
 					  setContext();
-					  msg("Parsing file %s...\n",yyFileName);
-					  current_root  = global_root ;
-					  initParser();
-					  current->reset();
-					  int sec=guessSection(yyFileName);
-					  if (sec)
-					  {
-					    current->name    = yyFileName;
-					    current->section = sec;
-					    current_root->addSubEntry(current);
-					    current          = new Entry;
+					  // parse line number
+  					  for (yyLineNr=0, i++;yytext[i+1]!=6;i++)
+  					    yyLineNr=yyLineNr*10+(yytext[i+1]-'0');
+					  if (yyLineNr==0) // start of a new base file
+					  {
+					    yyLineNr=1;
+					    msg("Parsing file %s ...\n",yyFileName);
+					    current_root  = global_root ;
+					    initParser();
+					    current->reset();
+					    int sec=guessSection(yyFileName);
+					    if (sec)
+					    {
+					      current->name    = yyFileName;
+					      current->section = sec;
+				      	      current_root->addSubEntry(current);
+					      current          = new Entry;
+					    }
+    					    BEGIN( FindMembers );
 					  }
-					  BEGIN( FindMembers );
 					}
 <*>\x0d
 <NextSemi>"{"				{
@@ -705,6 +709,9 @@
 <PackageName>";"			{
   					  BEGIN(FindMembers);
   					}
+<FindMembers>{B}*"friend"{BN}+[^;]*";"  { // ignore friend 
declarations (TODO: parse these and generate references for them)
+                                          lineCount();
+                                        }
 <FindMembers>{B}*"static"{BN}+     	{ //current->type += " static 
";
   					  current->stat = TRUE;
 					  lineCount();
@@ -3252,6 +3259,7 @@
 					                    memberGroupId = 
newMemberGroupId();
 					                    current->mGrpId = 
memberGroupId;
 					                    lastMemberGroupLine = yyLineNr;
+					                    lastMemberGroupFile = 
yyFileName;
 							  }
 							  else
 							  {
@@ -3744,7 +3752,7 @@
   if (memberGroupId!=NOGROUP)
   {
     warn(yyFileName,yyLineNr,"Warning: ignoring nested member group. "
-	"Previous command was found at line %d.",lastMemberGroupLine);
+	"Previous command was found at file %s line 
%d.",lastMemberGroupFile.data(),lastMemberGroupLine);
   }
   else if (!lastDefGroup.isEmpty())
   {
@@ -3763,6 +3771,7 @@
     memberGroupId = newMemberGroupId();
     current->mGrpId = memberGroupId;
     lastMemberGroupLine = yyLineNr;
+    lastMemberGroupFile = yyFileName;
   }
 }