Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

DynaPDF Manual - Page 20

Previous Page 19   Index   Next Page 21

Exception handling
Page 20 of 750
Customized Exception handling
By default, only fatal errors will stop processing. Warnings, syntax errors and so on are all
ignored. You can customize the exception handling to your own requirements with the property
Get/SetOnErrorMode(). With the following constants you can determine what kind of error
should be treated as fatal error:
typedef SI32 TErrMode;
#define emIgnoreAll
0x00000000 // default
#define emSyntaxError
0x00000001
#define emValueError
0x00000002
#define emWarning
0x00000004
#define emFileError
0x00000008
#define emFontError
0x00000010
#define emAllErrors
0x0000FFFF
#define emNoFuncNames
0x10000000 // Do not output function names
If a specific flag is set, DynaPDF treats this error type as fatal error; the internal resources will be
freed and all changes made before are lost.
DynaPDF never produces a damaged PDF file if a warning or error message was ignored, but
certain functions may be not executed. For example, if SetFont() cannot find the selected font, it
returns with a warning and no font is set, the active font (if any) is left unchanged.
If no other font was set before, it is not possible to output text. All text functions also return then
with a warning because there is no active font, but nothing more happens than a warning is
issued.
When a fatal error occurred, all functions are leaved immediately. No further warnings or error
messages are displayed. It is not possible to execute a function (except global properties which do
not change PDF objects directly) after a fatal error occurred.
There is no need to check the return value of each function, and there is no need to leave a
function block after a fatal error occurred. The internal error flag is cleared when
CreateNewPDF() is called the next time.
The special flag emNoFuncNames names can be used to avoid the output of the function name in
error messages. Error messages start normally always with the function name in which the error
occurred. While this information is useful during development, it is often not useful in an end
user application.
Remarks:
The constants are defined as enum in Visual Basic, VB .Net, and C#.
 

Previous topic: Special issues in Visual Basic and .Net

Next topic: Main object types