Three general classes of errors are possible (all of which will result in the function call returning zero) :
• Errors within the DYNLIB interface mechanism, such as failure to load the target library, find the target function, parameter errors, etc. These are recorded in the dlCtl.status member using DYNLIBE_xx values (arbitrary/specific to DYNLIB). Use Fn'libXL'Get'Status() to retrieve/dispay.
• OS-level errors within the target function or library. For example, invalid path, or file protection errors. These errors are defined by the OS/platform (Windows system error codes for Windows, errno values for UNIX). Use Fn'LibXL'Get'Syserr() to retrieve/display.
• Library/logic errors, i.e. functions that fail for reasons that neither DYNLIB nor the OS can detect. These are indicated by returning 0 for the function value (matching the underlying LibXL library behavior). You can use Fn'LibXL'GetErrorMessage() following one of these errors to get further details.
This LibXL library wrapper provides various services/options to simplify error handling to make application level code simpler. These are all set via flags passed to the Fn'LibXL'Load() function, which are defined in ashinc:dynlib.def.
|
LibXL’Load flags |
Description |
|
DLF_STATUS_BASERR |
Generate BASIC error 65 on abnormal status conditions within dynamic library interface |
|
DLF_SYSERR_BASERR |
Generate BASIC error 65 on OS-related system errors |
|
DLF_LOG_ERRORS |
Write status/syserr errors to ashlog |
|
DLF_PRINT_ERRORS |
Print status/syserr errors to screen |
|
DLF_MSGBOX_ERRORS |
Report status/syserr errors via MSGBOX |
The first two options (triggering a BASIC error 65) are ideal when errors are not expected, since you only have to put your error logic in one place in the error trap. The others relate to how errors are reported, also sparing the application from having to manage that aspect of error reporting.