I often use the project name in comments I write. However, up until now I hardcoded it. Now I realized that if the project name were to change, I would have to go through all the documentation parts and change it. Therefore, I wanted to ask if it is possible to simply reference the project name in the comment and let doxygen fill it out later.
/*! \brief This is the main function of the (project_name) project
*/
int main()
{
return 0;
}
I think what you are looking for is environment variables, which you can read about here.
The one you are looking for should be $(PROJECT_NAME).
To use it, see this answer.
Related
When using C++ with doxygen I would like to add to the class description from within a function. I basically want to add information about the function calls I am making.
class_name.h
/**
* This is the overall description of the class
*/
class ClassName
{
...
}
class_name.cpp:
void ClassName::randomFunction()
{
/**
* #class ClassName
*
* calls testData on stuff (this should be appended to the class description)
*/
testData(stuff);
}
Doxygen output:
<b>Detailed Description</b>
<br>
This is the overall description of the class
<br>
calls testData on stuff
This method works when I put the comment outside of a function, but does not show up anywhere if I put it within randomFunction as the example shows. In the end, I would like the reader of the documentation to see a description of the class followed by the snippet that I have in the example. This makes it easier to keep my documentation in sync with the code and immediately tells the user about important functions that I am calling.
The reason I want to do this is to document the network messages that the class makes in one place instead of having the user search through documentation on multiple member functions.
EDIT:
doxygen version is 1.8.5
added clarification
The used version of doxygen (1.8.5, August 23, 2013) is a bit old and it is advised to update to the current version (1.8.17).
To have code snippets or documentation snippets in an other place as well doxygen has the command \snippet (see http://doxygen.nl/manual/commands.html#cmdsnippet).
To group information in different places doxygen has grouping commands like \defgroup (http://doxygen.nl/manual/commands.html#cmddefgroup), \ingroup (http://doxygen.nl/manual/commands.html#cmdingroup), \addtogroup (http://doxygen.nl/manual/commands.html#cmdaddtogroup).
See also the grouping chappetr in the doxgen documentation (http://doxygen.nl/manual/grouping.html).
Working with C++ Builder 10 Seattle, and ComObj.hpp, plus digging up code snippets wherever I can find them, I have been able to make my Word doc look a lot like I want it to.
But it would really help if I had a link to the property names I can use when talking to each of:
Variant FWordApp.OlePropertyGet("Documents").
OleFunction("Add", StringToOleStr(t_template));
Variant FWordDoc = FWordApp.OlePropertyGet("ActiveDocument");
Variant FSelection = FWordApp.OlePropertyGet("Selection");
For example, I found a snippet that showed me how to create a table and write to its cells:
/* I want to get the current cursor position in the doc, but how? */
int headerlength = ??
/* The example I copied uses headerlength for both parameters
* to "Range". I'm not sure that's what I want to do... I need
* documentation to explain it. */
FTable = FWordDoc.OlePropertyGet("Tables").OleFunction("Add",
FWordDoc.OleFunction("Range", headerlength, headerlength),
RowCount, ColCount);
I have been searching for examples, but sadly VBA and .NET code are not helping me to understand the VCL usage with OlePropertyGet and OlePropertySet.
I'm hoping that having a list of legitimate properties will help me stumble along. Help, please?
I created a table following the flatbuffers tutorial and compiled it to C++ code. Say, its name is Doc.
In the tutorial, it is said:
Regardless of whether you used CreateMonster or MonsterBuilder, you
now have an offset to the root of your data, and you can finish the
buffer using:
FinishMonsterBuffer(fbb, mloc);
However, I can't find any method named FinishDocBuffer. The generated Doc class only has one method named Verify() in addition to getters. The generated DocBuilder class only has one method named Finish(). And there's only one function named CreateDoc() defined outside of those two classes.
Did I do something wrong, or should the official doc be updated?
FYI, I'm using latest flatbuffers code cloned from the git repo.
Update:
I found the example code didn't call any Finish*Buffer() method either.
Found the reason. I need to add this line to my doc.fbs file:
root_type Doc;
I'm trying to make my own full adder and some other devices as a sub-circuit in "Proteus" and use them several times in a bigger circuit.
The problem is when you copy a sub-circuit you need to rename all of its inner parts, otherwise, the parts with a same name in two sub-circuits would be considered as one, therefore you'd get some errors.
So I'd like to know if there is a way to define a full adder of my own and use it like "74LS183" which is a primitive device, and by primitive I mean it has been defined in the library.
From answer posted here
It's in the Proteus Help file:
SCHEMATIC CAPTURE HELP (F1) -> MULTI-SHEET DESIGNS -> Hierarchical Designs
See the section "Module Components":
Any ordinary component can be made into a module by setting the Attach Hierarchy Module checkbox on the Edit Component dialogue form.
The component's value is taken to be the name for the associated circuit,
and the component's reference serves as the instance name.
after this you can use your new implementation of that component with your new name. for making it available at library see "External Modules" section of proteus help.
The problem with copying is solved in "Proteus 8".not completely but sort of.
I mean you can copy a subcircuit without a need to change it's inner parts, but you must change the subcircuit name and I mean the bigger name above the subcircuit not the little one below it.
so there is no need to define a primitive.
I have a project which contains an RPC-invokable API. The project also contains some other code. I'd like to generate a clean documentation just for these API functions (for users working with the API). Yet it should still be possible to generate a documentation of the whole program, intended for the developers.
The API is split into several classes ("command modules"). First thing I did is tell Doxygen to only look at those files, of course. But these classes also have some code which is not part of the API I'd like to generate the documentation for (helper functions).
These invokable functions ("commands") have a special return type: CommandResult.
As an example, here is such an API class:
class CommandModuleFoo {
int privateHelperFunction();
int privateMember;
public:
int publicHelperFunction();
int publicMember;
public slots:
/** Some documentation. */
CommandResult myFunction1(int someArg);
/** Some documentation. */
CommandResult myFunction2();
};
Now the documentation should basically contain the following:
class CommandModuleFoo
Public members:
CommandResult myFunction1(int someArg)
Some documentation.
CommandResult myFunction2()
Some documentation.
Question:
I know that I can select only a subset of the project's files by simply just naming them in the INPUT variable of my Doxyfile. But can I also select only a set of functions using a pattern?
Since I guess this is not possible, can I tell Doxygen to only generate documentation for one section? Doxygen has section markers: \if...\endif can be used to exclude some part of the document but include them with the configuration variable ENABLED_SECTIONS. But I need the opposite. Is there something like ONLY_SECTION?
Possible workarounds:
I could use above-mentioned section conditions around every code except the commands I want to document. But that sounds very ugly.
I could set HIDE_UNDOC_MEMBERS to YES in order to only generate documentation for documented members, but that would make it impossible to generate also a full documentation of the program, if one wants to. (i.e. it forbids to document non-API functions). Also, detecting undocumented API-functions is then more difficult.
I currently use the second workaround.
You could do the following:
Use \internal in the documentation of internal functions (the non-commands in this case):
/**
* \internal
* This helper function does foo.
*/
void myHelperFunction();
Your commands use normal doxygen comments:
/**
* Some documentation.
*/
CommandResult myFunction();
Then, in your Doxyfile use INTERNAL_DOCS = YES if you compile the documentation of the whole program and INTERNAL_DOCS = NO (default) to compile your API documentation.
Basically, treat your program like it was a library. Library developers often encounter this problem: they obviously want to have a clean documentation for the users of the library which only contains exported stuff, while they (probably) also want to have a more verbose documentation for developers of the library.
PS. You can also use \internal to selectively include paragraphs of the documentation of a function, i.e. your documentation for the developers could include some more detail which is not important for the users of your API. For details consult the documentation of \internal.