Incorrect doxygen formatting on only one line - formatting

The heading at the start of the comment block shown in the C code below is formatted incorrectly in both HTML and PDF output as \verbatim text.
All other Doxygen comments I have in this file work perfectly (they are all VERY similar as the file provides functions that conform to a type).
I have tried removing all preceding Doxygen comments from the file (except the #name) to rule out incorrect block formatting closing, removing the heading spec (#'s) changing the heading text (eg "foo") in case of incorrect characters, removing the later \verbatim block, removing this entire comment block itself to see if the problem transferred to the next one, but nothing seems to change!!
How can I get the heading to format correctly?? Thanks.
code:
/** # *IDN? - Identification query #
* This query allows the instrument to identify itself. It responds with a `<`string`>` consisting of four fields
* separated by commas. The four fields are determined by constants defined in the application
* specific settings in config.h and appear in the following order:
* \verbatim MANUF,MODEL,SERIAL,FIRMW \endverbatim
* See the config.h file description for information on each of these fields.
*
* #param parameters None
* #param query `*IDN?`
*/
extern int16_t IDN (double * parameters, bool query);
How this looks in PDF:
How this looks in HTML:
EDIT: The comments for the OPC function:
/** # *OPC - Operation Complete Command. #
* This command causes the device to set the operation complete bit in the standard event status register when
* all pending device operations have completed.
*
* The query responds with an ASCII "1" when all pending device operations are complete.
*
* #param parameters None
* #param query `*OPC?`
*/
extern int16_t OPC (double * parameters, bool query);

Finally solved this, though Im still unsure as to the cause.
Basically I rewrote the documentation comment a bit at a time (I was trying to see if I could isolate any one item that caused it).
I started with a one word comment, when that appeared correctly I slowly added more bits, rebuilding after each addition. I now have the full comment, exactly as before, but now working as intended
Puzzling... maybe doxygen only rebuilt that part after it detected the comment being deleted and started again and that cleared whatever the issue was?? Meh, it's fixed anyway. Thanks for the suggestions.

Related

Meaning of (052) at the end of text literal?

Really just a curious question.
Here are a few examples of the same concern that I have since they are being exported to the FM "REUSE_ALV_GRID_DISPLAY" for parameter "it_fieldcat".
ls_fieldcat-seltext_l = 'Material number'(052).
ls_fieldcat-seltext_m = 'Material'(053).
ls_fieldcat-seltext_s = 'Mat.'(054).
I tried removing the numbers on the right and executed the program but I didn't see any differences and I also tried to see what happens inside debug mode but it only fills the field with the string value, am I missing something or is there something that I wasn't able to notice?
I've been tasked to create a copy of a program which originally joins multiple tables and filters them according to the Parameters from the SELECTION-SCREEN and then shows the results in an ALV Grid Report, but for the use case of the copy it should instead populate a table in ECC that we will then be replicating to BW side. I have successfully copied and modified it accordingly but I can't seem to understand what the numbers beside the strings are doing.
Can someone please explain what their use is, would be very grateful to see a few examples.
Thanks!
The number in the brackets is a text symbol defined as a part of the text elements of the program. Using the syntax 'Literal'(idf) replaces these literals in the program if the symbol is in the currently loaded text pool.

what this sign mean in sql query

i have the following code :
SELECT *
FROM tbl_doc
/*_archive*/
,
TBL_LOG#dblink
WHERE Prim_id='2121212';
What is /*_archive*/ mean ?
in my database we have :
tbl_doc_status
tbl_doc_archive
tbl_doc_save
From a /* sequence to the following */ sequence, as in the C programming language. This syntax enables a comment to extend over multiple lines because the beginning and closing sequences need not be on the same line.
MySQL Server supports certain variants of C-style comments. These enable you to write code that includes MySQL extensions, but is still portable, by using comments of the following form:
/*! MySQL-specific code */

Doxygen Alias with multiple commands

I do have some problems to define an Alias definition in doxygen when I have to use multiple commands in the alias definition.
What I am trying to achieve is actually the output of sample DD_32 below.
I currently don't know why the output of #DD{22, Test Description} looks different. Also tried to provide escaped quotes to the ALIAS definition, but still. No luck.
My alias definition is as follows:
ALIASES += DD{2}="\page DD_\1 \"Design \1\" \brief \2 #par Implementation:"
For testing I use the following code:
/**
* #page DD_31 Design 31
* #brief Descrition
* #par Implementation:
*/
/**
* #DD{22, Test Description}
*/
I would suspect, that the output is identical, but it looks like in the screenshot provided below:
As you can see, the \brief description is actually part of the page name.
Any hints how I could fix this issue?
Thanks a lot.
For completeness;
As proposed in the comments by albert, his pull request implements physical newlines in an alias by placing ^^ in between separate commands.
So, for example:
ALIASES += DD{2}="#page DD_\1 "Design \1" \brief \2 ^^ #par Implementation:"

What are the new documentation commands available in Xcode 5? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
One of Xcode 5's new features is the ability to document your own code with a special comment syntax. The format is similar to doxygen, but appears to only support a subset of those features.
Which commands are supported, and which ones aren't?
Do any of their usages differ from doxygen?
Here is an example of all the options I have found as of Xcode 5.0.2
That was generated with this code:
/** First line text.
Putting \\n doesn't create a new line.\n One way to create a newline is by making sure nothing is on that line. Not even a single space character!
#a Italic text #em with ##a or ##em.
#b Bold text with ##b.
#p Typewritter font #c with ##p or ##c.
Backslashes and must be escaped: C:\\foo.
And so do ## signs: user##example.com
Some more text.
#brief brief text
#attention attention text
#author author text
#bug bug text
#copyright copyright text
#date date text
#invariant invariant text
#note note text
#post post text
#pre pre text
#remarks remarks text
#sa sa text
#see see text
#since since text
#todo todo text
#version version text
#warning warning text
#result result text
#return return text
#returns returns text
#code
// code text
while (someCondition) {
NSLog(#"Hello");
doSomething();
}#endcode
Last line text.
#param param param text
#tparam tparam tparam text
*/
- (void)myMethod {}
Notes:
The commands must be in a /** block */, /*! block */, or prefixed with /// or //!.
The commands work with the # (headerdoc style) or the \ (doxygen style) prefix. (I.e. #b and \b both do the same thing.)
The commands usually come before the item they are describing. (I.e. if you are trying to document a property, the comment must come before the #property text.) They can come afterwards, on the same line, with /*!<, /**<, //!<, ///<.
You can add documentation to classes, functions, properties, and variables.
All of these commands appear in dark green text to signify that they are valid commands, except for #returns.
You may need to build your project (or restart Xcode) before the latest changes to your documentation appear.
Where to see the documentation:
1. During code complete, you will see the brief text:
This will show the brief text (with no formatting); if no brief text exists, it will show a concatenation of all the text up to the first #block; if none exists (e.g. you begin with #return), then it will concat all the text striping away all #commands.
2. Option-clicking an identifier name:
3. In the Quick Help Inspector panel
(See first screenshot.)
4. In Doxygen
Since the commands in Xcode 5 are compatible with Doxygen, you could download and use Doxygen to generate documentation files.
Other Notes
For a general introduction to Doxygen and how to document Objective-C code, this page seems like a good resource.
Descriptions of some of the supported commands:
#brief: will insert text at the beginning of the description field, and is the only text that will appear during code completion.
The following don't work:
\n: doesn't generate a newline. One way to create a newline is by making sure nothing is on that line. Not even a single space character!
\example
The following are not supported (they don't even appear in dark green):
\cite
\docbookonly
\enddocbookonly
\endinternal
\endrtfonly
\endsecreflist
\idlexcept
\mscfile
\refitem
\relatedalso
\rtfonly
\secreflist
\short
\snippet
\tableofcontents
\vhdlflow
\~
\"
.
::
\|
Apple reserved keywords:
Apple uses what appears to be reserved keywords that only works in their documentation. Although they appear in dark green, it looks like we cannot use them as Apple does. You can see examples of Apple's usage in files such as AVCaptureOutput.h.
Here is a list of some of those keywords:
#abstract, #availibility, #class, #discussion, #deprecated, #method, #property, #protocol, #related, #ref.
At best, the keyword will cause a new line in the Description field (e.g. #discussion). At worst, the keyword and any text following it will not appear in the quick help (e.g. #class).
Swift 2.0 uses the following syntax:
/**
Squares a number.
- parameter parameterName: number The number to square.
- returns: The number squared.
*/
Notice how #param is now - parameter.
You can also now include bullets in your documentation:
/**
- square(5) = 25
- square(10) = 100
*/
Senseful:
You may need to build your project before the latest changes to your documentation appear.
Sometimes this hasn't been enough for me. Closing Xcode and opening the project back up usually remedies those cases.
I'm also getting different results in .h files and .m files. I can't get new lines when the documentation comments are in a header file.
Most of the formatting has changed for Swift 2.0 (as of Xcode7 ß3, also true in ß4)
instead of :param: thing description of thing
(as it was in Swift 1.2)
it is now - parameter thing: description of thing
Most of the keywords have been replaced by - [keyword]: [description] instead of :[keyword]: [description]. Currently the list of keywords that don't work includes, abstract, discussion, brief, pre, post, sa, see, availability, class, deprecated, method, property, protocol, related, ref.

Generate random GUID

I want to generate a random UUID like in Java with UUID.randomUUID().
I came up with the function GUID_GENERATE and used it like this
DO 5 TIMES.
CALL FUNCTION 'GUID_CREATE'
IMPORTING
ev_guid_16 = ev_guid_16
ev_guid_22 = ev_guid_22
ev_guid_32 = ev_guid_32.
WRITE: /, ev_guid_16, ev_guid_22, ev_guid_32.
ENDDO.
The result of this program is always the same GUID. I need a new random one at every request.
I want to use it as a primary key in database table. This key will be transmitted via a Web Service to a Java application and user there as identifier, too.
Do you have any ideas how I can generate random UUID/GUID in ABAP?
First of all you are using a function module that is obsolete. The comment at the beginning of the source code states that.
*"----------------------------------------------------------------------
* NOW this function has been replaced, see note 935047 "BINK215094
* 28.6.2006 The function module has been switched to the new UUID methods
* which exist in the class cl_system_uuid
* - due to compatibility reasons we catch the exceptions
* - sy-subrc not touched manually
* (sy-subrc was set in case of an error when calling the former
* 'RFCControl' kernel-call, but it wasn't evaluated and finally
* overwritten when leaving this function)
*"----------------------------------------------------------------------
Please use class CL_SYSTEM_UUID and the following methods:
IF_SYSTEM_UUID_STATIC~CREATE_UUID_X16
IF_SYSTEM_UUID_STATIC~CREATE_UUID_C22
IF_SYSTEM_UUID_STATIC~CREATE_UUID_C26
IF_SYSTEM_UUID_STATIC~CREATE_UUID_C32
Are you absolutely sure the created GUID is always the same? Because this shouldn't be happening. Note that the difference between them can be just one character when you generate them inside a fast loop.