Main Page | Features | Central Services | csv-Files | Types | Transfer
| Access | API-C
| API-VB/ActiveX | API-Java
| Examples | Downloads
Categories
Here is a list of
documented API Categories with brief descriptions:
|
TINE Local Alarm
Server plus API routines |
|
|
TINE Client-side API
Routines |
|
|
TINE Local History
Server module plus API routines |
|
|
TINE Server engine and
registration API routines |
|
|
TINE Socket control
(for experts) |
|
|
TINE System API routines
|
|
|
TINE Cycler API
routines for shared libraries |
|
|
TINE API tools |
|
|
TINE console command
line API |
When using the TINE API in projects in C or C++ you will
generally only need to include "tine.h".
In some cases however, depending on what other packages are also being used,
there could be macro definition 'collisions'. For instance, the standard
template libraries macro #define 'out_of_range'
as does TINE. If for some reason both headers need to be included in the same
module, the following solution is suggested: define (using the -D switch on the
compiler in your make file) tine_decorated_constants
to effectively re#define all lower case TINE macro
definitions (such as the error codes) using a prefix of 'tdc_'.
Thus, 'out_of_range' will become 'tdc_out_of_range'.
Likewise, some upper case macro definitions could potentially come in conflict
with other packages (e.g. CF_TEXT in TINE and Windows). If this also presents a
problem for your project, then by defining TINE_DECORATED_CONSTANTS at
the compiler level, all upper case macro defined constants will be prefixed
with 'TDC_'. Thus, 'CF_TEXT' will become 'TDC_CF_TEXT'.
Under most circumstances you will not have to worry about such details. The
usual strategy is to try to separate the routines dealing with a specific package
into separately compilable C modules.
Note that the standard download package ‘setup’
will make both single-threaded and multi-threaded builds of the tine libraries
(as well as ‘static’ or ‘shared’ libraries).
So you have some lee-way in deciding how to construct your client or
server application. Under most
circumstances it is advised to use the multi-threaded builds, and if many
clients and servers are to run on the same host, then to make use of the shared
libraries as well (.DLLs on windows systems or .so libraries on Unix systems).
In any event, the application should start and
keep a ‘cycler’ going throughout the application’s lifetime. In multi-threaded builds a call to SystemSetCycleTimer() will suffice, as this will launch an independent thread
with a tight loop around SystemCycle(). This is, of course, not necessary. But if omitted it is the application’s
responsibility to call SystemCycle() regularly. Note
that a ‘tight loop’ here does not impose a high CPU load, as SystemCycle()
will typically be in a ‘wait state’ while ‘select()ing’
over socket descriptor sets (with a timeout on the order of a clock tick).
1.5.8