| fb-doc 0.2 documentation tool for FreeBasic

- Main Page
- Tutorial
- Data Structures
- Files

All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Pages
Files used

fb-doc currently uses two external files. It tries to load the context when needed and continues without the context when the files aren't present. fb-doc searches for the files in the EXEPATH (the folder of the fb-doc binary).

# ../doc/c_src

This folder gets created by fb-doc to write the file output. It's used to collect the translations from the C_source emitter. The back-end read its input from here.

# fb-doc.lfn

The suffix lfn means list of function names. This file is used in the C_SOURCE emitter to create pseudo function calls in a function body. It gets created by the ListOfFunction emitter when using (option –list) and it isn't used in Geany mode (option –geany, emitters GtkDocTemplates and DoxygenTemplates).

Allthough it's usually created by fb-doc, it also can get manipulated by any text editor.

The file contains the names of all functions in the source code. Member functions of a UDT are listed as they are named in the function body (ie TypeName.FunctionName). The first line is empty. Further lines contain the names, one in each line, including the dot in case of a member function. The lines must be separated by a single line feed character (LINUX line end = 'CHR(10)'). So be careful when we edit on DOS / windows (ie use Geany and switch to LF line ends).

This file is needed when running as a filter for Doxygen to create the caller and callees graphs. Therefor the bodys of the function have to include the function calls. fb-doc checks all words in a function body against the known function names. Any match gets emitted as a pseudo function call (with empty parameter list).

Since in this mode Doxygen serves the file names in any order and fb-doc gets started new for each file, it doesn't know about a function declaration from file A when working on file B. Therefor the function names have to be served from an external source. They get red from this file at each program start.

The file offers an additional way to control the context of the caller and callees graphs. Only functions listed in this file gets included in the C source (and in the graphs).

When this file isn't present fb-doc continues execution without any message and the function bodys of the pseudo C code are empty. This means no caller or callees graphs will be created.

# empty.txt

This file is used in Geany mode (option –geany). When we send an empty block to fb-doc (place the cursor in an emppty line and call fb-doc) then a standard text gets emitted to our source file. This is a documentation block

- for a section, when in gtk-doc mode or
- for a file, when in Doxygen mode.

We can replace these standard blocks by the context of this file. When fb-doc finds this file in the EXEPATH it emits its context instead of the standard text to fill an empty line. The file gets red each time when passing an empty block, so we can edit the file and use the new context without restarting Geany or fb-doc.

Usually this file contains a comment block with any kind of documentation. When the file isn't present the standard text of the emitter gets emited.

# External Moduls (*.so / *.dll)

fb-doc can use external emitter modules. These are executable binaries, compiled and linked as a library for dynamic linkage, either by using the FreeBasic compiler or any other compiler / linker combination. These files may have any name and get the system specific file name extension (= suffix) .so on LINUX or .dll on windows.

Such files aren't necessary for basic usage of fb-doc. They are used for external emitters to extend the fb-doc features and get loaded on demand (option –emitter) at run-time, see Extending fb-doc for details. So you may have one or more files with one of these suffixes in your working directory.