I have a doxygen header for a function as follows:
/** Some description.
#param[in] grid1 First grid
#param[in] grid2 Second grid
#pre grid1 and grid2 must be of the same dimensions
*/
I'd like grid1 and grid2 to be specially highlighted in the pre-conditions section of the generated documentations, since they are parameters. In my mind, I should be able to do something like
#pre #grid1 and #grid2 must be the same size
But this doesn't work.
Any thoughts on how to achieve this?
It would be nice if # automatically linked to the function argument definition. However, I can't see anyway of doing this in the automatic link generation section of the doxygen manual.
Having looked at the documentation HTML source it seems that parameters seem to be simply styled as strong and with the class paramname. So something like
#pre <strong class="paramname">grid1</strong> and
<strong class="paramname">grid2</strong> must be the same size.
should give you the results you want. Clearly this is overly verbose to write out each time. However, you should be able to define a custom command, say \paramname, to do this so you could just write
#pre \paramname{grid1} and \paramname{grid2} must be the same size.
Edit: This can be achieved with the configuration file alias
ALIASES += paramname{1}="<strong class="paramname">\1</strong>"
Landed here looking for the answer, but found it elsewhere.
Use \p to indicate that the next word is a function parameter.
And, of course, you can use # instead of \.
/** Some description.
#param[in] grid1 First grid
#param[in] grid2 Second grid
#pre #p grid1 and #p grid2 must be of the same dimensions
*/
See Doxygen Special Commands reference.
Related
I have some source code (STM32 Peripherial Lib) with existing doxygen parameters which my Doxygen Builds without Problems.
For my project I want to generate a document with all functions in each file and a specific information which I want to add to the functions. But I want to keep the old informations for another doxygen configuration.
Is that possible?
I already added this for testing:
\ifnot "SECTION_DEFINE"
<normal Doxygen Parameters from original Source Code>
\elsif "SECTION_DEFINE"
#brief Function Check TODO
\endif
With this I could deactivate the existing documentation, but I need to write this \ifnot \elsif \endif to every function.
Can I just declare a Tag and only generate the documentation for this specific tag?
Kind regards
Andi
You may create a "related page" where only your additional information will be displayed with the \xrefitem command. As \xrefitem will also create a special text section within your original documentation you may want to combine it with your original idea of using section labels and conditional documentation. To top this concept off, use aliases in order to make your documentation more readable.
Consider this example code:
/** ST documentation
* foobar
* \exclusive for andi's function \endif
*/
void andreas(void);
/** ST documentation
* foobar
* \exclusive for beni's function \endif
*/
void benjamin(void);
You may use this alias in your Doxyfile: exclusive=\if SECTION_DEFINE \xrefitem viparea "Exclusive" "VIPs".
As long as SECTION_DEFINE is not defined, the "exclusive" information will not be included in your documentation. As soon as this section is defined, a "related page" (here: viparea.html) is created in your HTML documentation containing your documented items (here: andreas and benjamin) with the exclusive paragraph behind the command. The result:
I would like to create a "cleanup" extension that replaces various characters (quotes by guillemets) in all kinds of textfields in TYPO3.
I thought about extending <f:format.html> or parseFunc, but I don't know where to "plug in" so I get to replace output content easily before it's cached.
Any ideas, can you give me an example?
If you don't mind regexing, try this:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['cleanUpQuotes'][] = \NAMESPACE\Your\Extension::class;
Insert it into ext_localconf.php and this part is done.
The next step is the class itself:
public function cleanUpQuotes(TypoScriptFrontendController $parentObject)
{
$parentObject->content = DO_YOUR_THING_HERE
}
There also is another possibility which could replace any strings in the whole page - as it operates on the rendered page (and not only on single fields).
You even can use regular expressions.
Look at my answer -> here
In buildbot's waterfall page, the buttons show the status of each build step. If the step runs, it simply shows 'Ran'. I want to edit this to give better info to the user. Where can I add this change from?
From the documentation of buidlbot 8.12, the keyword parameters of all buildsteps
include:-
description
This will be used to describe the command (on the Waterfall display) while the command is still running. It should be a single imperfect-tense verb, like compiling or testing. The preferred form is a list of short strings, which allows the HTML displays to create narrower columns by emitting a tag between each word. You may also provide a single string.
descriptionDone
This will be used to describe the command once it has finished. A simple noun like compile or tests should be used. Like description, this may either be a list of short strings or a single string.
In the python definitions of your buildsteps, you should set the descriptionDone
keyword parameter to an appropriate description for the completion of each buildstep.
I have some GWT code here. I am trying to change the background color of a widget:
this.getElement().setAttribute("backgroundColor", backgroundColor);
this.getElement().setPropertyString("backgroundColor", backgroundColor);
this.getElement().getStyle().setProperty("backgroundColor", backgroundColor);
Usually in code I can tell by the name of the function what the code does... but in this case all three lines of code looks the same and "read the same"! (Reading the javadoc did not help either.I went to the javadoc because that usually helps me understand what code does. The javadoc did not help.)
My question to you is: Please explain what is the differences between these three lines of code (for instance why do you need to call getStyle())? Why does the last line work?
this.getElement().getStyle().setProperty("backgroundColor", backgroundColor);
is the only line that access the actual style information, properties and attributes manipulate the element directly and don't have anything to do with the Style that is associated with an element.
And just as an addition, you should really be using a style sheet and changing the style instead of setting inline this way.
It is the difference between
<tag backgroundColor="#f0f0f0">
and
<tag style="background-color:#f0f0f0">
This is somewhat of an educated guess...
Line 1 you are accessing the element's attributes not the styling attributes.
Line 2 would access properties on the element not the styling.
Line 3 actually gets the styling properties and then changes them accordingly.
My SSRS report contains 7 input parameters and while running my report the size of the parameter(i.e. length) is increasing.
One of my input parameter(drop down list) may contain 100 characters so the size is not constant but i want to place all parameters in 2 lines or 3 lines(in a row).
Now it is coming 2 parameters per a row
Please advice
As gbn indicates, it's not easy to change the built in report server method of presenting the parameters. SSRS likes to always use two parameters per line, presented in the order that they exist in the report (which must match the dependency order.)
So the alternatives that gbn mentions: Both involve building a "Wrapper" application: some custom code or a web page that you can code however you like to get the parameters. Then you call Reporting Services, either in code or by passing a formatted URL with your parameters. The report can be displayed in a frame, new window, or passed as a stream to where ever you'd like.
The URL access is pretty straightforward and reliable: I often use it either by hand (to create "favorites") or in code.
http://msdn.microsoft.com/en-us/library/ms153586.aspx
For what you are looking for, these might be more work than you expected, but they will be extremely flexible for your interface.
Jamie
You can certainly do that, just right click on the RDL file in the solution explorer and select view code. then move the XML tags named <ReportParameter Name="Nameofparameter"> under <ReportParameters> according to where ever you want to position. And then save it. thats it!!!
The report parameters are kind of floating in values of 2, so if u have 4 report parameters then it will be shown as 1,2 next line 3,4. Best of luck!!
Use ASP.NET for the paramaters and a ReportViewer control or URL access to render. Seriously.
I don't know of any option to present parameters any way other then the default
I believe you could try using jQuery. The report parameters are rendered in a table under a div tag with class sqlrv-ParameterContainer. Write a jQuery or JavaScript function that will extract the full innerHTML from this div ie. the table content and then extract the table row information like the <label> or <input> tags.
Create your desired table structure with <table><tr><td>{extracted sections}</td><td></td></tr></table> or leave it to your requirement...
Then just append this new HTML structure in place of the original default structure.
In jQuery it will be like
$(".sqlrv-ParameterContainer").html();
which will give you the entire table structure that comes inside the parameter. Use XML parsing and get the input controls and all. Extract these controls as-is, don't change anything.
$(".sqlrv-ParameterContainer table").remove(); // it will remove the SSRS rendered default table from DOM
$(".sqlrv-ParameterContainer table").appendChild('<table><tr>......</tr></table>'); // Append your custom html structure here....
This was something that came to my mind quickly... I would suggest you test it... :)
This doesn't help the OP with SSRS-2008 but in case it helps others - Microsoft have improved this in SSRS 2016 - parameters can now be easily managed via the GUI in Report Builder / Visual studio:
https://www.intertech.com/ssrs-parameters-2016-update/