I would like to start documenting my code properly, but am unsure where the best place is to put it for HeaderDoc to read. I read the following phrase in the HeaderDoc documentation which makes me think the intended location (from Apple's point of view) is in the header files?
Instead of specifying a single input file (as above), you can specify an input directory if you wish. HeaderDoc will process every .h file in the input directory (and all of its subdirectories), generating an output directory of HTML files for each header that contains HeaderDoc comments.
Is this right? Does it make a different where I put my documentation?
Related
The JavaVM framework contains a sub-framework, JavaNativeFoundation framework. This sub-framework contains a header file, JNFRunLoop.h, that I need.
According to Apple documentation:
#import <Framework_name/Header_filename.h>
In both cases, Framework_name is the name of the framework and
Header_filename is the name of a header file in that framework or in
one of its subframeworks.
#import <JavaVM/JNFRunLoop.h> does not work (JavaVM/JNFRunLoop.h file not found).
I tried adding the sub-framework headers to the header search path, and while this allows me to import it, it gives a compile-time error which is mentioned in the documentation:
The umbrella header files and the subframework header files contain
preprocessor variables and checks to guard against the inclusion of
subframework header files.
I ultimately need to do this:
[JNFRunLoop performOnMainThreadWaiting:YES withBlock:block];
which won't work until I can import that header file. Any ideas?
The authors of the library have put that guard on purpose. Are you sure you are doing the right thing?
If the library allows modifications the right way would be to take it and adapt it to your needs.
If you need a quick and dirty way to call that method, you can try to declare it inside your ".m" file like so:
#interface JNFRunLoop
+ (void)performOnMainThreadWaiting:(BOOL)w withBlock:(void (^)(void))b;
#end
(it must match to how it is declared in JNFRunLoop.h in terms of name and parameter types)
After this declaration it becomes available for calling. Note that this won't work, if the library requires some special initialization steps, or if that function name is mangled in their binary or not present their.
I have a Swift project and have add a cocoapod, which is written in Objective-C. It has header and implementation files. From what I understand, to use/import these files into my Swift files, I need to add a bridging file.
I found this site describing how to do this manually, since the Objective-C files are already part of my project (from the cocoapod).
http://www.learnswiftonline.com/getting-started/adding-swift-bridging-header/
1.) Navigate to your project build settings and find the “Swift Compiler – Code Generation” section. You may find it faster to type in “Swift Compiler” into the search box to narrow down the results.
2.) Next to “Objective-C Bridging Header” you will need to add the name/path of your header file. If your file resides in your project’s root folder simply put the name of the header file there.
I don't have a Objective-C Bridging Header in that section and it doesn't appear you can add new entries there.
I'm using Xcode 7.3.1. Anyone have some idea how this should be done?
Are you sure you looked at the correct Build Settings section, search with the keyword Swift compiler - General in the search field as describe below and then you can find it.
You need to create the header file first. It is a regular Objective-C header file and should be named <Your app or framework name>-Bridging-Header.h. For any Objective-C headers you want Swift to know about add an import statement to the newly created header file. Then follow your previous steps.
There is also a hidden header that gets created for you called <Your app or framework name>-Swift.h. If you need to access any Swift classes from an Objective-C file import this header.
I have a simple doxygen project consisting of Doxyfile and a configuration file, project.txt. In the project.txt file, I have some manually written documentation that uses cross-references to auto generated documentation from my code, and it all works fine.
I am trying to break down my project into subsections, like:
project.txt
disclaimer.txt
readme.txt
So, I've put Doxygen markup code into disclaimer.txt and readme.txt, and I updated the EXAMPLE_PATH in my Doxyfile to be:
EXAMPLE_PATH=./
Finally, in project.txt, I just added the lines:
\include disclaimer.txt
\include readme.txt
I expected disclaimer.txt and readme.txt to be imported into project.txt so they are treated as Doyxgen markup, but instead, they are interpreted as text, and are rendered as-is in a code block, as if wrapped by \code and \endcode tags, making the include operation useless.
Is there some way to include additional Doxygen configuration files and actually have them parsed?
Thank you.
Quoting the docs:
\include This command can be used to include a source file as a block of code.
Which seems to agree with the behaviour you see.
I am not sure if you can include pages into others as you want.
The best solution I can see is to use \subpage instead, which will both create a link to the other pages and make them subpages of the main page (this will show in the html related pages section as a dropdown hierarchy).
Usage inside project.txt would be:
\subpage disclaimer
\subpage readme
Supposing that disclaimer.txt contains a line like \page disclaimer Disclaimer
Also make sure that *.txt is in your FILE_PATTERNS.
I don't think you can include Doxygen config files at arbitrary points in your code like that. I know you could add it to you file list though, etc:
INPUT = ../PATH_TO_SOURCE_CODE_HEADER_1.h \
./project.txt \
./disclaimer.txt \
./readme.txt
Also, make sure each of your .txt files is wrapped with /** and */ if you're using C, for example.
i was reading the doc about localization and internationalization , but it's not really clear for me : can you explain me the link between the .lproj files, and/or the Localizable.strings file (if those are connected) ?
Or by any chance, if you know where i could see/download an example of an app using localized text?
I've seen the Localizable.strings file with the sample code 'NavBar' (from the doc), but nothing yet about a sample code using .lproj files.
Thanks for your help
It's very simple: create a folder for each localization, with the localization name followed by ".lproj", there you put any localizable file (you can also localize images) and your Localizable.strings (which contains the text returned by the obj-c API for localization). Don't forget to add the files in your resources, in Xcode.
For exemple, if you have 3 localizations, you could have this structure:
PROJECT_DIR/
- en.lproj/
Localizable.strings
- it.lproj/
Localizable.strings
- pt.lproj/
Localizable.strings
en.lproj/Localizable.strings have the english strings, and so on. Add the three Localizable.strings on your Xcode (it will be smart enough to group then) and it's done.
To use the localized strings just call NSLocalizedString(NSString *key, NSString *comment), it will automatically look for the key in your Localizable.strings file for the current locale and return the value associated with the key. For more information about NSLocalizedString see NSLocalizedString.
In reference to this related question on stackoverflow:
If you create a constants file, how do you "link" to it in your target, so you don't have to
#import "Constants.h"
in every file you use constants?
You really should be using #import "Constants.h" every place you want to use the constants within it; Objective-C is a C-based language.
Furthermore, you aren't "linking" to it either when you put an #import directive in your code or if you put one in your prefix file. In both cases, the contents of the file are included in the text stream fed to the compiler by the preprocessor.
Finally, you shouldn't generally add random things to your prefix file. (Panagiotis Korros referred to this as "your pre-compiled header file," but that's slightly incorrect; your prefix file is used to generate the pre-compiled header file.) If you keep your build settings consistent across projects, and use the same name for your prefix files across projects, Xcode will actually cache and re-use the precompiled versions for you very aggressively. This is defeated by putting project-specific contents in them.
You can put the import line in your pre-compiled header file.
That is the .pch file named after you application name.
When I use the constant in more file inside my application, normally I use the .pch file (find it under "Supporting Files" folder).
Into my .pch file I insert the constant, for example:
static const int NAME_CONSTANT = 200;
and use NAME_CONSTANT into all file inside my project without import never file because the .pch is pre-compiled header file.