* add additional members to a group that is defined in more detail elsewhere. The title of the group is optional for this command, so you can use /** \addtogroup It can be used exactly like \defgroup, but when the group has been defined already, then it silently merges the existing documentation with the new one. If you don't want doxygen to enforce unique labels, then you can use \addtogroup instead of \defgroup. You will get an error message when you use the same group label more than once. Groups themselves can also be nested using these grouping markers. The markers can be put in the documentation of the group definition or in a separate documentation block. To avoid putting \ingroup commands in the documentation for each member you can also group members together by the open marker before the group and the closing marker after the group. You can make an entity a member of a specific group by putting a \ingroup command inside its documentation block. The second argument is the name or title of the group as it should appear in the documentation. The first argument of the command is a label that should uniquely identify the group. To define a group, you should put the \defgroup command in a special comment block. Members of a group can be files, namespaces, classes, functions, variables, enums, typedefs, and defines, but also other groups. You can document a group as a whole, as well as all individual members. Modules are a way to group things together on a separate page. For pages there is a third grouping mechanism referred to as subpaging. The second mechanism works within a member list of some compound entity, and is referred to as a 'member groups'. These groups are called 'modules' in the documentation. One mechanism works at a global level, creating a new page for each group. > relational database is painful, don't do it! Check out ObjectStore.Doxygen has three mechanisms to group things together.
#DOXYGEN CUSTOM TAGS CODE#
> If flattening out C++ or Java code to make your application fit in a > This SF.net email is sponsored by: ObjectStore. > the tag, but I realise this may be less convenient/pretty. > block (as is available for the other formats) in which you could put > have to be ignored, so also tags whose name is a typo), so I'm not a big fan > avoid any tag checking for the other output formats (since any unknown tags > This is not possible at the moment, and adding it with XML/HTML syntax would
#DOXYGEN CUSTOM TAGS HOW TO#
> Are there any plans to add something like this? Or is this already possible, and I am just too dumb to find it? Or can somebody point me in the direction of how to do that myself? > //! This is Foo, a model of \xmltagbegin model Bar \xmltagend > this, a doxygen style syntax like the following would be just as useful, Also, there is no need to use standard XML/HTML syntax for
> think this is a very useful feature (I know it is exactly what I need > However, in the XML output, it will be preserved: > Then in the HTML/LaTeX/RTF/man output, the element will be suppressed, since there is no way to interpret it: > Is it possible to add the ability to process custom XML tags to doxygen's XML backend? I want to embed my own XML elements in the documentation, which shall be preserved in the XML output, but may be ignored in other modes (since they have no predefined 'meaning' there). > I have asked this question earlier already, but unfortunately received no usable response. (hitting reply-all and deleting the single recipient) "I want to embed my own XML elements in the documentation, which shall be preserved in the XML output, but may be ignored in other modes" It sounds a great tag, Dimitri, convenient exactly to Uwe's request. This is Foo, a model of \xmlonly \endxmlonly Bar \xmlonly \endxmlonly
0 kommentar(er)
