 |
IDS peak AFL
v1.3.0
|
|
IDS peak AFL
v1.3.0
|
IDS peak AFL provides host based auto features for IDS cameras.
The library requires the use of C99 for the client application.
You also need to have the IDS peak genericAPI and IDS peak IPL libraries and their headers.
In order to use IDS peak AFL you need to include the interface header file peak_afl.h and link your application with the ids_peak_afl library.
In order to run an application the shared libraries must be found by the system.
For Windows copy the deployed shared libraries (dll) into the folder with the applications executable.
For Linux add the path to the deployed shared libraries (so) to LD_LIBRARY_PATH.
This section defines several terms that are used throughout the IDS peak AFL library.
The term library is used to refer to the IDS peak AFL library and its implementation.
This section describes some basic principles and programming paradigms of the library.
The application programmer can rely on the library following these principles' throughout the whole interface.
Wherever possible the library guarantees strong exception safety.
Strong exception safety is also known as commit or rollback semantics.
The point of strong exception safety is that a failed operation has no side effects. This means that the system status after a failed function is the same as it was before the function call.
Please note that may not be possible to achieve this goal for every specific situation.
In principle, all functions of the library return a status code of type peak_afl_status.
If a function succeeds it will return PEAK_AFL_STATUS_SUCCESS. If a function fails it will return an error code.
It is strongly recommended checking the return value of every library function call for an error indication.
If a function returns an error code, i.e. PEAK_AFL_ERROR, the details on the error can be queried via peak_afl_GetLastError. See also Last Error Handling.
The library stores the last error separately for each application thread.
A descriptive message on the last error that occurred in the current thread context can be queried via peak_afl_GetLastError. This message describes the error and its cause in as much detail as possible.
The last error is not cleared after peak_afl_GetLastError has been called.
It is therefore strongly advised to evaluate the last error only in the immediate context of a failed library function call, i.e. a library function indicating an error by a peak_afl_status error code.
A code example on how to query the last error is given in the section Two Staged Data Query.
Several library functions provide data of dynamic size in a memory buffer that is to be provided by the application. As the size of the data depends on the required memory buffer, the size can not be known a priori.
To access such data, the application should implement the following procedure:
The following code demonstrates this procedure by the example of peak_afl_GetLastError.
peak_afl_status errCode = PEAK_AFL_STATUS_SUCCESS;
char* errMsg = NULL;
size_t errMsgSize = 0;
// For peak_afl_GetLastError the second parameter is the buffer parameter.
// For Stage One, i.e. the size query, we pass a buffer parameter of NULL.
peak_afl_status status = peak_afl_GetLastError(&errCode, NULL, &errMsgSize);
if (status == PEAK_AFL_STATUS_SUCCESS)
{
// The size of the last error message was successfully stored in errMsgSize.
// This is the size of memory we have to allocate to receive the message.
errMsg = (char*)malloc(errMsgSize);
memset(errMsg, 0, errMsgSize);
// For Stage Two, i.e. the data query, we pass the allocated memory as the buffer parameter.
status = peak_afl_GetLastError(&errCode, errMsg, &errMsgSize);
if (PEAK_AFL_SUCCESS(status) == PEAK_AFL_TRUE)
{
// The last error message was successfully stored in errMsg.
}
}