The EurekaLog Developer Guide

Appendix D - Classes and interfaces

Use this appendix to find class ancestry, available members and their contracts. Logging interface methods refer to the equivalent function in appendix A instead of repeating its tutorial. The final section provides TEurekaModuleOptions property names and option-specific values.

Defaults appear only where a declaration or an option description supplies them. A missing exception list is not a no-throw guarantee; use each entry's return values, requirements and remarks. A declaration does not establish thread safety or transfer ownership unless the accompanying contract says so. Internal, unstable and unimplemented surfaces remain visibly marked.

Names are grouped by declaring unit, then by type or class. Member headings retain the owner name. Cross-references to appendices A-D refer to this book; no external help is needed. Same-name declarations in different units are qualified so their contracts cannot be confused. Syntax blocks are declarations for lookup, not standalone programs.

Unit map: EBase, EBaseClasses, ECallStack, EClasses, EComponent, EDebugDWARF, EDebugEL, EDebugEL7, EDebugExportBase, EDebugExports, EDebugJCL, EDebugMAB, EDebugMAB2, EDebugMap, EDebugME, EDebugMS, EDebugStabs, EDebugTD32, EDialog, EDialogCGI, EDialogConsole, EDialogIntraWeb, EDialogISAPI, EDialogService, EDialogWER, EDialogWinAPIEurekaLog, EDialogWinAPIEurekaLogDetailed, EDialogWinAPIMSClassic, EDNS, EException, EExceptionManager, EFreeze, ELogBuilder, ELogging, EMapParserBase, ESend, ESendAPIBugZilla, ESendAPIExceptionless, ESendAPIFogBugz, ESendAPIGitHub, ESendAPIGitLab, ESendAPIJIRA, ESendAPIJSON, ESendAPIMantis, ESendAPIRedmine, ESendAPIYouTrack, ESendMailMAPI, ESendMailShell, ESendMailSMAPI, ESendMailSMTP, ESendWebFTP, ESendWebHTTP, EThreadsManager, EZip.

Capability boundary. TELDebugInfoDWARF and TELDebugInfoStabs are declared but marked not implemented. No public callable contract is specified for thirteen named dialogs; their individual entries identify that limit. A WER name or WER configuration property is not a promise that WER reporting is available in a given build.

EBase

Constructor TThreadEx.Create

Creates an instance of a thread object.

public
constructor Create;
overload;
constructor Create(
  CreateSuspended: Boolean
); overload;
constructor Create(
  const AName: String;
  const AELEnabled: Boolean = Boolean(2
)); overload;
constructor Create(
  CreateSuspended: Boolean;
  const AName: String;
  const AELEnabled: Boolean = Boolean(2
)); overload;

Parameters.

CreateSuspended [in, opt] — If CreateSuspended is False, Execute (appendix D, TThreadEx.Execute) is called immediately after the constructor. If CreateSuspended is True, Execute (appendix D, TThreadEx.Execute) is not called until after the Start method is called. Default is False.
AName [in, opt] — Defines thread's name. Thread name is arbitrary text string which can contain any combination of characters. Thread name will be visible in IDE's debugger. It also will be used by EurekaLog in bug reports. Default is empty name (no name; TID will be used to identify this thread).
AELEnabled [in, opt] — Defines EurekaLog status in created thread. This argument is ignored if you compile your application without EurekaLog. Default is the same state as current thread.

Remarks.

Call Create to create a thread in an application.

EEurekaLogGeneralError

Base exception class for EurekaLog's exceptions.

EEurekaLogGeneralError = class(Exception);

Remarks.

You can use this exception class in exception filters or exception events to filter out EurekaLog-related exceptions.

TThreadEx

Abstract class to create separate threads of execution.

TThreadEx = class(TThreadHook);

Remarks.

TThreadEx is EurekaLog's replacement for TThread class. TThreadEx offers two additional arguments in constructor, which allows you to control thread's name and EurekaLog's state in this thread.

Create a descendant of TThreadEx to represent an execution thread in a multithreaded application. Each new instance of a TThreadEx descendant is a new thread of execution. Multiple instances of a TThreadEx derived class make an application multithreaded.

When an application is run, it is loaded into memory ready for execution. At this point it becomes a process containing one or more threads that contain the data, code and other system resources for the program. A thread executes one part of an application and is allocated CPU time by the operating system. All threads of a process share the same address space and can access the process's global variables.

Define the thread object's Execute (appendix D, TThreadEx.Execute) method by inserting the code that should execute when the thread is executed.

Important. You must call the inherited implementation in your overridden Execute (appendix D, TThreadEx.Execute) method.

Lifetime notes from the class examples. Threads created with TThreadEx are EurekaLog-enabled by default; the constructor can disable that state. Anonymous threads are marked FreeOnTerminate by default: do not access the thread reference after starting such a thread. The examples also show AutoHandleException for automatic handling, instead of manually analyzing FatalException. Chapter 15 supplies the complete workflow.

TThreadEx.AutoHandleException

Allows you to enable automatic thread's exception handling.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - automatically invoke EurekaLog for exceptions in thread. False (default) - do not alter standard behaviour; store thread exception in FatalException property; you must analyze this exception manually.

Remarks.

With the default value False, TThreadEx stores a fatal exception in FatalException for the caller to examine, just as TThread does. Inspect the result only after the thread has finished, or handle it through an appropriate termination callback. Chapter 15 gives the complete ownership and callback workflow.

With True, EurekaLog calls HandleException (appendix A) automatically for the thread's fatal exception. FatalException is still populated; automatic reporting does not make that property disappear.

Configure AutoHandleException and other lifetime settings before starting the thread. When FreeOnTerminate is True, do not access the thread reference after Start: the thread may already have destroyed itself.

TThreadEx.Execute

Defines thread's execution.

protected
procedure Execute;
reintroduce;
virtual;

Remarks.

Override Execute and insert the code that should be executed when the thread runs. Execute is responsible for checking the value of the Terminated property to determine if the thread needs to exit.

Important. You must call the inherited implementation in your overridden Execute method.

A thread executes when Create (appendix D, Constructor TThreadEx.Create) is called if CreateSuspended set to False, or when Start is first called after the thread is created if CreateSuspended set to True.

EBaseClasses

TELDebugInfoSource

Base class for debug information provider.

TELDebugInfoSource = class(TCheckedInterfacedObject);

Remarks.

This is the base class for debug information providers. Debug information provider is a class which can load and parse debug information in one specific format. Debug info provider can be registered in EDebugInfo unit (appendix C, EDebugInfo).

Child classes must override at least InitializeSource and GetLocationInfo methods. Most providers will also override Heuristic method.

ECallStack

Constructor TEurekaBaseStackList.Create

Creates call stack object instance and (optionally) builds/traces stack.

public
constructor Create(
  const AFirstAddr: Pointer;
  const AStackFrame: Pointer = nil;
  const ATopOfStack: Pointer = nil;
  const AStartLevel: Integer = -1;
  const ALevelsNumber: Integer = -1;
  const ADebugDetails: TEurekaDebugDetails = [ddUnit, ddProcedure, ddSourceCode];
  const AThreadID: DWord = 0;
  const ARunningThread: Boolean = True;
  const AGetDebugInfo: Boolean = True;
  const AAllowedMethods: DWord = TracerInvalidMask;
  const AStackOffset: PtrUInt = 0;
  const AContext: Pointer = nil
); overload; virtual;
constructor Create;
overload;
virtual;

Parameters.

AFirstAddr [in, optional] — Code address to add to stack. May be nil, which means do not add any additional items to stack.

When specified:

must point to a code location (not to the stack).
the specified location will be added as first item to final call stack
AStackFrame [in, optional] — Specifies current stack pointer. This value indicate starting pointer to start tracing process. May be nil (default), which means use current stack pointer (i.e. trace entire stack).

When specified:

must point to stack.
this value must point to a valid stack frame.
this value must be less than ATopOfStack.
ATopOfStack [in, optional] — Specifies top of the stack. This value indicate ending value for tracing process. May be nil (default), which means use current stack limits (i.e. trace entire stack).

Usually this value is not specified, unless you want to build call stack for another (external) thread.

When specified:

must point to stack.
must be greater than AStackFrame.
AStartLevel [in, optional] — Indicates how many items (i.e. levels) should be skipped from start of call stack. Default is -1, which means "do not remove any items".
ALevelsNumber [in, optional] — Limits length (items' count) of call stack. Default is -1, which means "do not limit call stack".
ADebugDetails [in, optional] — Only store locations with this level of details. Default is [ddUnit, ddProcedure, ddSourceCode].
AThreadID [in, optional] — A thread ID (this is not thread handle).

Mark call stack items as belonging to the specified thread. Default is 0, which means current thread.

This argument is used to build call stack for another (external) thread.

ARunningThread [in, optional] — Set this argument to True when build call stacks manually. Value of False is used to indicate error (exception) thread. Default is True.
AGetDebugInfo [in, optional] — Retrieve debug information.

False - retrieve only RAW pointers; UnitName, ClassName, ProcedureName and LineNumber will be empty.

True - retrieve full information. Each possible property will be filled. This works slower.

AAllowedMethods [in, optional] — Mask for call stack tracing methods to use. Default is DefaultTracerMask (appendix C) (which is "EurekaLog 7 RAW"). Do not use this argument. Use GetTracer (appendix A) or GetTracerClass (appendix A) functions.

Remarks.

This is object constructor, which creates instances of call stack.

Warning. Do not create instances of TEurekaBaseStackList class. Use EurekaCallStackClass (appendix C) to create default call stack class or use GetTracerClass (appendix A) to get specific class.

Note. There are two overloaded Create constructors. Create without arguments will create object instance without building call stack. You can trace stack on request by using Build (appendix D, TEurekaBaseStackList.Build) method. Create with arguments will create object instance AND build call stack. This overload is equal to Create + Build.

Constructor TGenericStackList.Create

Creates call stack class with specified tracer.

public
constructor Create(
  const ATracerNo: Integer = TracerUndefined
); reintroduce;

Parameters.

ATracerNo [in] — Number of stack tracer. Numbers are listed as TracerXYZ constants in EStackTracing (appendix C) unit. Some examples are: TracerRawJCL TracerRawMadExcept TracerLeaksRAW TracerFramesJCL TracerLeaksFrame TracerWindows Any other TracerXYZ value...

Remarks.

This class can be used to build call stack with arbitrary stack tracing method (except EurekaLog tracing methods).

Warning. Do not use this class for EurekaLog stack tracing.

Use Build (appendix D, TEurekaBaseStackList.Build) method to trace stack after creation.

TEurekaBaseStackList

Base call stack class.

TEurekaBaseStackList = class(TCheckedInterfacedPersistent);

Remarks.

This is parent class for any call stack builder/tracer classes.

Note. This is base abstract class. Do not create instances of this class. Use EurekaCallStackClass (appendix C) to create default call stack class or use GetTracerClass (appendix A) to get specific class.

TEurekaBaseStackList.Build

Builds call stack.

public
procedure Build(
  const AFirstAddr: Pointer = nil;
  const AStackFrame: Pointer = nil;
  const ATopOfStack: Pointer = nil;
  const AStartLevel: Integer = -1;
  const ALevelsNumber: Integer = -1;
  const ADebugDetails: TEurekaDebugDetails = [ddProcedure, ddUnit, ddSourceCode];
  const AThreadID: DWord = 0;
  const ARunningThread: Boolean = True;
  const AGetDebugInfo: Boolean = True;
  const AMethods: DWord = TracerInvalidMask;
  const AStackOffset: PtrUInt = 0;
  const AContext: Pointer = nil
);

Parameters.

AFirstAddr [in, optional] — Code address to add to stack. May be nil (default), which means do not add any additional items to stack.

When specified:

must point to a code location (not to the stack).
the specified location will be added as first item to final call stack
AStackFrame [in, optional] — Specifies current stack pointer. This value indicate starting pointer to start tracing process. May be nil (default), which means use current stack pointer (i.e. trace entire stack).

When specified:

must point to stack.
this value must point to a valid stack frame.
this value must be less than ATopOfStack.
ATopOfStack [in, optional] — Specifies top of the stack. This value indicate ending value for tracing process. May be nil (default), which means use current stack limits (i.e. trace entire stack).

Usually this value is not specified, unless you want to build call stack for another (external) thread.

When specified:

must point to stack.
must be greater than AStackFrame.
AStartLevel [in, optional] — Indicates how many items (i.e. levels) should be skipped from start of call stack. Default is -1, which means "do not remove any items".
ALevelsNumber [in, optional] — Limits length (items' count) of call stack. Default is -1, which means "do not limit call stack".
ADebugDetails [in, optional] — Only store locations with this level of details. Default is [ddUnit, ddProcedure, ddSourceCode].
AThreadID [in, optional] — A thread ID (this is not thread handle).

Mark call stack items as belonging to the specified thread. Default is 0, which means current thread.

This argument is used to build call stack for another (external) thread, assuming that you pass CPU context and other values belonging to the specified thread. Please note that target thread must be a current thread or a suspended thread.

However, if you want to build a call stack for another (external) thread - there is an easier way: use the BuildForThread method.

ARunningThread [in, optional] — Set this argument to True when build call stacks manually. Value of False is used to indicate error (exception) thread. Default is True.
AGetDebugInfo [in, optional] — Retrieve debug information.

False - retrieve only RAW pointers; UnitName, ClassName, ProcedureName and LineNumber will be empty.

True - retrieve full information. Each possible property will be filled. This works slower.

AMethods [in, optional] — Mask for call stack tracing methods to use. Default is DefaultTracerMask (appendix C) (which is "EurekaLog 7 RAW"). Do not use this argument. Use GetTracer (appendix A) or GetTracerClass (appendix A) functions.
AContext [in, optional] — A pointer to CPU context record. Supply this value when available.

Remarks.

Traces CPU stack and looks for return addresses. Each found return address will be added to the list (object). You can walk though stack by using Count and Items properties.

TEurekaBaseStackList.GetCurrentInstruction

Returns current instraction for current thread.

public
class function GetCurrentInstruction: Pointer;
static;

Return value.

Pointer to code segment, which points to current execution point.

This will be the pointer to code which called this method (GetCurrentInstruction).

Remarks.

Use this routine to obtain current execution point.

This method is often used when building call stack. Call stack includes callers (because it's call stack), but it do not hold current instruction. So, you can use this method to obtain current execution point and pass it as AFirstAddr value.

TEurekaBaseStackList.GetCurrentStackFrame

Returns current CPU stack frame for current thread.

public
class function GetCurrentStackFrame: ETypes.PStackFrame;
static;

Return value.

Pointer to stack's data, which points to current stack frame.

Remarks.

This value is very similar to GetCurrentStackPointer (appendix D, TEurekaBaseStackList.GetCurrentStackPointer), except it is adjusted to point to stack's frame block.

x86-64: use GetCurrentStackPointer instead.

Tip. Don't use this function to walk through stack. Use Caller or GetTracer (appendix A).

TEurekaBaseStackList.GetCurrentStackPointer

Returns current CPU stack pointer for current thread.

public
class function GetCurrentStackPointer: Pointer;
static;

Return value.

Pointer to stack's data, which points to current stack position.

Remarks.

Current position is most recent position of the stack. Since stack is growing backwards, this value points to the logical end of the stack, but physical beginning.

TEurekaBaseStackList.GetCurrentTopOfStack

Returns top of CPU stack for current thread.

public
class function GetCurrentTopOfStack: Pointer;
static;

Return value.

Pointer to stack's data, which points to top of stack.

Remarks.

Top of stack is greatest pointer possible. Since stack is growing backwards, this value points to the logical beginning of the stack, but physical end.

TEurekaStackListV6

Stack tracing class for EurekaLog 6 method.

TEurekaStackListV6 = class(TEurekaBaseStackList);

Remarks.

Use this class to build call stacks by using EurekaLog 6 method.

Tip. Avoid using classes directly. Use EurekaCallStackClass (appendix C)/ GetTracer (appendix A)/GetTracerClass (appendix A).

TEurekaStackListV7

Stack tracing class for EurekaLog 7 RAW method.

TEurekaStackListV7 = class(TEurekaBaseStackList);

Remarks.

Use this class to build call stacks by using EurekaLog 7 RAW method.

Tip. Avoid using classes directly. Use EurekaCallStackClass (appendix C)/ GetTracer (appendix A)/GetTracerClass (appendix A).

TGenericStackList

Common stack tracing class.

TGenericStackList = class(TEurekaBaseStackList);

Remarks.

Use this class for building call stack by any method, except EurekaLog.

Warning. Do not use this class for EurekaLog stack tracing.

Tip. Avoid using classes directly. Use EurekaCallStackClass (appendix C)/ GetTracer (appendix A)/GetTracerClass (appendix A).

TGenericStackList.Tracer

Indicates stack tracer used to build call stack.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

One of TracerXYZ values from EStackTracing unit: TracerRawJCL TracerRawMadExcept TracerLeaksRAW TracerFramesJCL TracerLeaksFrame TracerWindows Any other TracerXYZ value...

Remarks.

This property holds ATracerNo argument, which was used in Create constructor.

EClasses

TEurekaModuleOptions

EurekaLog options.

TEurekaModuleOptions = class(TInterfacedPersistent);

Remarks.

This class represents EurekaLog options. EurekaLog options are usually stored as one instance per one loaded executable module. However, you can also create a new instance of this class on your request (to create custom options).

Usually you work with this class via CurrentEurekaLogOptions (appendix A) global function or via Options property of other EurekaLog classes (such as dialogs, call stacks, etc.).

Options are stored as named pairs text (name=value). Each option occupies one line only. Value is encoded to remove special characters (non-printable, line breaks, etc.). Complex values can be cached.

Note. If you need to constantly use some option value - consider to save it into variable to optimize performance.

The option-property reference later in this appendix supplies the available names, values and caveats. Change global options through CurrentEurekaLogOptions (EModules, appendix A), or exception-local Options during callbacks. This is not a second accessor named CurrentEurekaModuleOptions.

EComponent

TEurekaLogEvents

EurekaLog 7 events component.

TEurekaLogEvents = class(TComponent);

Remarks.

EurekaLog 7 component can be used as simple way to react to EurekaLog's events, similar to the TApplicationEvents component.

This component provides a quick access to EurekaLog events. Normally a EurekaLog event handler is procedure or method which are registered (subscribed) to events via Register* routines in the EEvents (appendix C) unit. By using this component you can just double-click on events in IDE's Object Inspector to create handlers. No code writing is necessary.

Caution!

While using component is very easy, you should be aware that any component lives as long as its container (form, frame or data module) lives. Thus, any event handler which you create with component will be inactive after your form closes.

For this reason it's best to avoid component at all and use event handlers directly. Any event handler can be registered via the EEvents (appendix C) unit. Best place to register event handler - initialization sections of your units.

If you still want to use EurekaLog component - best option is to place it on the main form of your application.

Note. It's perfectly fine to have multiple EurekaLog components in your application.

For more information and descriptions of the events itself - please see the EEvents (appendix C) unit.

TEurekaLogEvents.OnAttachedFilesRequest

Wrapper for OnAttachedFilesRequest (appendix B, TELEvAttachedFilesRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnAttachedFilesRequest event (appendix B, TELEvAttachedFilesRequestMeth).

TEurekaLogEvents.OnBeginReportGen

Wrapper for OnBeginReportGen (appendix B, EEvents.TELEvReportGenMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnBeginReportGen event (appendix B, EEvents.TELEvReportGenMeth).

TEurekaLogEvents.OnCustomBugID

Wrapper for OnCustomBugID (appendix B, TELEvCustomBugIDMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnCustomBugID event (appendix B, TELEvCustomBugIDMeth).

TEurekaLogEvents.OnCustomButtonClick

Wrapper for OnCustomButtonClick (appendix B, TELEvCustomButtonClickMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnCustomButtonClick event (appendix B, TELEvCustomButtonClickMeth).

TEurekaLogEvents.OnCustomDataRequest

Wrapper for OnCustomDataRequest (appendix B, TELEvCustomDataRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnCustomDataRequest event (appendix B, TELEvCustomDataRequestMeth).

TEurekaLogEvents.OnCustomFileName

Wrapper for OnCustomFileName (appendix B, TELEvCustomFileNameMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnCustomFileName event (appendix B, TELEvCustomFileNameMeth).

TEurekaLogEvents.OnCustomWebFieldsRequest

Wrapper for OnCustomWebFieldsRequest (appendix B, TELEvCustomWebFieldsRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnCustomWebFieldsRequest event (appendix B, TELEvCustomWebFieldsRequestMeth).

TEurekaLogEvents.OnEndReportGen

Wrapper for OnEndReportGen (appendix B, EEvents.TELEvReportGenMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnEndReportGen event (appendix B, EEvents.TELEvReportGenMeth).

TEurekaLogEvents.OnExceptionAction

Wrapper for OnExceptionAction (appendix B, TELEvExceptionActionMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnExceptionAction event (appendix B, TELEvExceptionActionMeth).

TEurekaLogEvents.OnExceptionError

Wrapper for OnExceptionError (appendix B, TELEvExceptionErrorMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnExceptionError event (appendix B, TELEvExceptionErrorMeth).

TEurekaLogEvents.OnExceptionNotify

Wrapper for OnExceptionNotify (appendix B, TELEvExceptionNotifyMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnExceptionNotify event (appendix B, TELEvExceptionNotifyMeth).

TEurekaLogEvents.OnPasswordRequest

Wrapper for OnPasswordRequest (appendix B, TELEvPasswordRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnPasswordRequest event (appendix B, TELEvPasswordRequestMeth).

TEurekaLogEvents.OnRaise

Wrapper for OnRaise (appendix B, TELEvRaiseMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnRaise event (appendix B, TELEvRaiseMeth).

TEurekaLogEvents.OnReproduceRequest

Wrapper for OnReproduceRequest (appendix B, TELEvReproduceRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnReproduceRequest event (appendix B, TELEvReproduceRequestMeth).

TEurekaLogEvents.OnZippedFilesRequest

Wrapper for OnZippedFilesRequest (appendix B, TELEvZippedFilesRequestMeth) event.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

User-supplied event handler.

Remarks.

For the detailed description please see OnZippedFilesRequest event (appendix B, TELEvZippedFilesRequestMeth).

EDebugDWARF

TELDebugInfoDWARF

Declared provider placeholder; explicitly documented as not implemented. Do not select it expecting debug-information support.

TELDebugInfoDWARF = class(TELDebugInfoSource);

Remarks.

Not implemented yet.

EDebugEL

TELDebugInfoNative

Implements support for modern (latest) EurekaLog Debug Info format

TELDebugInfoNative = class(TELDebugInfoSource);

Requirements.

Debug Format

EurekaLog Debug Info format 8.0.0+

Remarks.

This is native debug format for your EurekaLog version. Supports embedded (injected) EurekaLog Debug Info and external debug info in .eldbg files. Additional standalone .elsym files are also supported.

EDebugEL7

TELDebugInfoNativeOld

Implements support for obsolete EurekaLog Debug Info format

TELDebugInfoNativeOld = class(TELDebugInfoSource);

Requirements.

Debug Format

EurekaLog Debug Info format from 4.x up to (including) 7.x.

Remarks.

Supports embedded (injected) EurekaLog Debug Info.

EDebugExportBase

TELDebugInfoExportsBase

Base class for DLL Exports Debug Info

TELDebugInfoExportsBase = class(TELDebugInfoSource);

Remarks.

Implements support for reading DLLs export table. Heuristic.

EDebugExports

TELDebugInfoExports

Implements support for DLL Exports Debug Info

TELDebugInfoExports = class(TELDebugInfoExportsBase);

Remarks.

Heuristic.

EDebugJCL

TELDebugInfoJedi

Implements support for JEDI Code Library (JCL) Debug Info (JDBG/JclDebug)

TELDebugInfoJedi = class(TELDebugInfoSource);

Requirements.

Debug Format

JclDebug Debug Info Format v1

Remarks.

This is native debug format for JCL Library. Supports embedded (injected) JCL Debug Info and external debug info in .jdbg files.

EDebugMAB

TELDebugInfoMab

Implements support for obsolete Synopse mORMot Debug Info

TELDebugInfoMab = class(TELDebugInfoSource);

Requirements.

Debug Format

Synopse mORMot Debug Info Format v1

Remarks.

This is former debug format for Synopse mORMot Library. Supports embedded (injected) mORMot Debug Info and external debug info in .mab files.

EDebugMAB2

TELDebugInfoMab2

Implements support for modern Synopse mORMot 2 Debug Info

TELDebugInfoMab2 = class(TELDebugInfoSource);

Requirements.

Debug Format

Synopse mORMot Debug Info Format v2

Remarks.

This is native debug format for Synopse mORMot Library. Supports embedded (injected) mORMot Debug Info and external debug info in .mab files.

EDebugMap

TELDebugInfoMap

Implements support for .map files debug info

TELDebugInfoMap = class(TELDebugInfoSource);

Remarks.

Only RAD Studio (Delphi and C++ Builder) .map files are supported.

EDebugME

TELDebugInfoMadExcept

Implements support for madExcept Debug Info

TELDebugInfoMadExcept = class(TELDebugInfoSource);

Requirements.

Debug Format

madExcept Debug Info Format v3

Remarks.

Supports embedded (injected) madExcept Debug Info and external debug info in .mad files. Experimental, use with caution. For migration/backward compatibility only.

EDebugMS

TELDebugInfoSymbols

Implements support for Microsoft Debug Info

TELDebugInfoSymbols = class(TELDebugInfoExportsBase);

Requirements.

Debug Format

Debug Info formats supported by the DbgHelp and SymSrv DLLs (such as DBG, PDB).

Remarks.

This is a wrapper around DbgHelp.dll and SymSrv.dll. Requires these DLLs to be present/deployed. DbgHelp is a single thread DLL, which means routing all debug info requests to a single thread. Which can cause a lot of slow down in multi-threaded applications. We don't recommend to use it on production. Consider converting debug information to some other supported format.

EDebugStabs

TELDebugInfoStabs

Declared provider placeholder; explicitly documented as not implemented. Do not select it expecting debug-information support.

TELDebugInfoStabs = class(TELDebugInfoSource);

Remarks.

Not implemented yet.

EDebugTD32

TELDebugInfoTD32

Implements support for Turbo Debugger (TD32) Debug Info

TELDebugInfoTD32 = class(TELDebugInfoSource);

Remarks.

Supports embedded (injected) TD32 Debug Info and external debug info in .tds files.

EDialog

EDialog.TMessageBoxDetailedDialog (MessageBox detailed dialog)

Dialog name: MessageBox detailed dialog. Qualified name: EDialog.TMessageBoxDetailedDialog.

No public declaration, member list, or behavioral contract is specified here. This is a named dialog entry, not a documented callable API. The label does not establish implementation status or platform support. Use the operational dialog choices in chapter 24; WER availability must not be inferred from this entry.

EDialog.TMessageBoxDialog (MessageBox dialog)

Dialog name: MessageBox dialog. Qualified name: EDialog.TMessageBoxDialog.

EDialog.TNullDialog (Null dialog)

Dialog name: Null dialog. Qualified name: EDialog.TNullDialog.

EDialog.TRTLHandlerDialog (RTL dialog)

Dialog name: RTL dialog. Qualified name: EDialog.TRTLHandlerDialog.

TBaseDialog

Base class for all dialogs.

TBaseDialog = class(TObject);

Remarks.

This is base abstract class for error dialogs in EurekaLog. It provides service methods and implements common interface.

Actual (non abstract) dialogs are implemented as child sub-classes for this class. Each dialog class must be registered via RegisterDialogClass (appendix A) or RegisterDialogClassFirst (appendix A) functions.

Each child class must implement at least ShowModalInternal method (protected), where it must implement functionality of the dialog.

EDialogCGI

EDialogCGI.TWebDialog (CGI)

Dialog name: CGI. Qualified name: EDialogCGI.TWebDialog.

EDialogConsole

EDialogConsole.TConsoleWriterDialog (Console)

Dialog name: Console. Qualified name: EDialogConsole.TConsoleWriterDialog.

EDialogIntraWeb

EDialogIntraWeb.TWebDialog (IntraWeb)

Dialog name: IntraWeb. Qualified name: EDialogIntraWeb.TWebDialog.

EDialogISAPI

EDialogISAPI.TWebDialog (ISAPI)

Dialog name: ISAPI. Qualified name: EDialogISAPI.TWebDialog.

EDialogService

EDialogService.TEventLogDialog (System Log)

Dialog name: System Log. Qualified name: EDialogService.TEventLogDialog.

EDialogWER

EDialogWER.TWERDialog (WER)

Dialog name: WER. Qualified name: EDialogWER.TWERDialog.

EDialogWinAPIEurekaLog

EDialogWinAPIEurekaLog.TEurekaLogDialog (EurekaLog)

Dialog name: EurekaLog. Qualified name: EDialogWinAPIEurekaLog.TEurekaLogDialog.

EDialogWinAPIEurekaLogDetailed

EDialogWinAPIEurekaLogDetailed.TEurekaLogDetailedDialog (EurekaLog detailed)

Dialog name: EurekaLog detailed. Qualified name: EDialogWinAPIEurekaLogDetailed.TEurekaLogDetailedDialog.

EDialogWinAPIMSClassic

EDialogWinAPIMSClassic.TMSClassicDialog (MS Classic)

Dialog name: MS Classic. Qualified name: EDialogWinAPIMSClassic.TMSClassicDialog.

EDNS

EDNSError

Base class for DNS errors.

EDNSError = class(EEurekaLogGeneralError);

EException

TEurekaExceptionInfo

Exception information class.

TEurekaExceptionInfo = class(TInterfacedPersistent, IInterface);

Remarks.

This is class for storing exception information. It's used everywhere in EurekaLog when you need to work with exceptions.

TEurekaExceptionInfo.ActiveControl

Window handle of active control.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Window handle of active control inside active window. Can be 0.

Remarks.

Contains information about GUI elements when exception was raised.

Tip. This handle may no longer be valid when you read this property. Control may be deleted right after exception was raised.

TEurekaExceptionInfo.ActiveControlClass

Class name of active control.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Window class name. Such as "EDIT".

Remarks.

Contains information about GUI elements when exception was raised.

TEurekaExceptionInfo.ActiveControlText

Text of active control.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Arbitrary text from active control.

Remarks.

Contains information about GUI elements when exception was raised.

TEurekaExceptionInfo.ActiveForm

Window handle of active window.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Window handle of active window. Can be 0.

Remarks.

Contains information about GUI elements when exception was raised.

Tip. This handle may no longer be valid when you read this property. Window may be deleted right after exception was raised.

TEurekaExceptionInfo.ActiveFormClass

Class name of active window.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Window class name. Such as "TForm1".

Remarks.

Contains information about GUI elements when exception was raised.

TEurekaExceptionInfo.ActiveFormText

Text of active window.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Arbitrary text from active window.

Remarks.

Contains information about GUI elements when exception was raised.

TEurekaExceptionInfo.AdditionalInfo

Custom data.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Arbitrary user-supplied data for the exception.

Remarks.

This value is not used by EurekaLog and can be set to any value for user purposes.

Note. This property can be used to override exception message (appendix D, TEurekaExceptionInfo.ExceptionMessage) for dialogs. See UseExceptionComments option.

TEurekaExceptionInfo.Address

Exception address.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Pointer to code segment. It points to CPU's instruction which raised the exception.

Remarks.

This is exception address. It points to exact code location of exception. If you want a human-readable description instead of RAW address - use the .ExceptionLocation (appendix D, TEurekaExceptionInfo.ExceptionLocation) property.

This value is added as top item to call stack to indicate exact location of exception. This valus is also listed in bug report on "CPU" page as "EXP" field.

Note. This value is adjusted for software exceptions, so it will point to "call raise" instruction of "raise Exception" Pascal code line.

TEurekaExceptionInfo.BaseException

Base exception.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Exception information for base exception. If no such exception exists - returns nil.

Remarks.

BaseException specifies the innermost exception.

Read the value of the BaseException property to obtain the innermost exception. If there are no inner exceptions that triggered the current one, BaseException returns the current exception; otherwise BaseException inspects the inner exceptions until it finds the first one that triggered the chain of exceptions.

TEurekaExceptionInfo.BugID

BugID value.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A hash that unique identifies exception.

Remarks.

This is a full BugID value.

BugID is a 4-byte unsigned integer (LongWord) which is used to identify exception. Two exception with the same BugID value are considered to be the same. BugID is used to establish uniqueness for many EurekaLog features (such as "Do not save duplicate exceptions", etc.). BugID is also used by EurekaLog Viewer tool when importing exceptions from multiple bug report files to eliminate duplicates. Two bug reports are considered to be duplicates of each other if they are bug reports about exceptions with the same BugID.

BugID consists of two parts. Hi-word is defined by EurekaLog. Lo-word is not used by EurekaLog and it's left for your customization.

Hi-word of BugID is a CRC16 value of string (" BugID ident (appendix D, TEurekaExceptionInfo.BugIDSource)") which includes application and module identification, exception class and two lines from call stack. "BugID ident" does not include exception message and exact error location (address). Only human-readable names are taken from call stack (unit name, class name and routine name). Thus, BugID will not change when you rebuild your application.

You can alter BugID (either by appending custom lo-word or fully replace it) in OnCustomBugID event handler.

Tip. It's not recommended to alter this value. Use CustomID (appendix D, TEurekaExceptionInfo.CustomID) to alter user part of BugID value.

Tip. Use BugIDStr (appendix D, TEurekaExceptionInfo.BugIDStr) to get human-readable string representation of BugID value.

TEurekaExceptionInfo.BugIDSource

Source information for BugID.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Application description + module description + exception class + call stack (first few items with debug info). Delimited with #0 characters.

Remarks.

This is source string for building BugD value (hi-word, i.e. the EurekaLog-part of it).

TEurekaExceptionInfo.BugIDStr

String representation of BugID property.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Hex-encoded BugID property.

Remarks.

Use this property to get human-readable string representation of BugID (appendix D, TEurekaExceptionInfo.BugID).

TEurekaExceptionInfo.CallStack

Exception call stack.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Call stack for exception.

Remarks.

This call stack includes address of exception as first item.

TEurekaExceptionInfo.Context

CPU state.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Contains CPU information for exception.

Remarks.

This property contains low-level CPU information captured from hardware. This is system data type (non-Delphi). It's specific to hardware (CPU architecture).

Tip. It's not recommended to use this property.

TEurekaExceptionInfo.Cursor

Mouse cursor.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Cursor descriptor.

Remarks.

Indicates mouse cursor shape when exception was raised.

TEurekaExceptionInfo.CursorPos

Mouse cursor position.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Absolute desktop coordinates of mouse cursor position.

Remarks.

Indicates mouse position when exception was raised.

TEurekaExceptionInfo.CustomID

Custom part of BugID value.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Low-word of BugID property.

Remarks.

This property allows you to modify "custom" part of BugID value.

Tip. Changes in this property will result in changes inside BugID property.

TEurekaExceptionInfo.ExceptionClass

Exception class.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Class of exception object (if present). Examples: 'Exception', 'EAccessViolation', 'EStreamError', etc.

Remarks.

Class name of original exception object.

TEurekaExceptionInfo.ExceptionCode

Exception error code.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Error code that represents exception object.

Remarks.

This property contains low-level error code associated with this exception. For example, it could be $C0000005 for access violation exception, or $0EEDFADE for Delphi exceptions.

Tip. You can use this property to return from thread function, or pass to functions like TerminateThread, TerminateProcess. Just don't forget to make a type conversion (avoid range-check errors) if your code requires Integer type.

TEurekaExceptionInfo.ExceptionExternal

Indicates if exception object is created by external module (DLL).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Handle of an external module if you exception object is created in external module (DLL), 0 otherwise.

Remarks.

This property indicates if exception object from .ExceptionObject was created in another executable module (DLL). Exception may be raised in another module, but exception object can still be created by current module. If you need to check if exception itself was raised in external module - check .Address property.

Note. This property is always 0 if you have just one module in your app, or if you are using run-time packages.

TEurekaExceptionInfo.ExceptionLocation

Exception address as text.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Textual human-readable description of the exception address. It describes the CPU's instruction which raised the exception.

Remarks.

This is exception address. It points to exact code location of exception. If you want a RAW address instead of a human-readable description - use the .Address (appendix D, TEurekaExceptionInfo.Address) property.

This value is added as top item to call stack to indicate exact location of exception.

Note. This value is adjusted for software exceptions, so it will point to "call raise" instruction of "raise Exception" Pascal code line.

TEurekaExceptionInfo.ExceptionMessage

Exception message.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Error message (if present). Examples: 'Error Message', 'Access violation at address 0040532 in module "Project1.exe". Write at address 00000000', 'Stream read error', etc.

Remarks.

Human-readable error message from exception object.

Note. You can alter this property, but doing so will totally overwrite exception message (both for error dialogs and bug reports). If you want to preserve original exception message, but display custom exception message to user - use AdditionalInfo (appendix D, TEurekaExceptionInfo.AdditionalInfo) property.

TEurekaExceptionInfo.ExceptionNative

Indicates if exception is compatible with current RTL.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True if you can safely cast .ExceptionObject property to TObject class, False otherwise.

Remarks.

This property indicates if exception object from .ExceptionObject is compatible with RTL in current executable module. It is typically True, but may be False when exception comes from another module (DLL) compiled with different IDE version. For example, a Delphi 2007 exception being catched in Delphi XE - ExceptionNative would be False.

Warning. The ExceptionObject (appendix D, TEurekaExceptionInfo.ExceptionObject) property may be NIL when ExceptionNative is True. For example, if you are looking at already deleted inner (nested) exception.

TEurekaExceptionInfo.ExceptionNumber

Number of exceptions.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Global exception counter for this exception.

Remarks.

EurekaLog keeps global exception counter. Each time an exception occurs - this counter is increased and its current value is saved to this property.

This property is updated when exception is raised. It doesn't matter if exception will be handled, processed, etc.

TEurekaExceptionInfo.ExceptionObject

Exception object.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Exception object type-casted as pointer. I.e. it's a pointer to data of exception object.

Remarks.

This is pointer to original exception object.

Warning. Since exception may come from another (external) executable module (rare cases, but could happen), then exception object may be not a Delphi object. Do not try to cast this value to Exception or TObject unless you're 100% sure about this.

Use Address (appendix D, TEurekaExceptionInfo.Address), ExceptionClass (appendix D, TEurekaExceptionInfo.ExceptionClass) and ExceptionMessage (appendix D, TEurekaExceptionInfo.ExceptionMessage) properties instead.

TEurekaExceptionInfo.ExceptionRecord

Exception record.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Contains system information for exception.

Remarks.

This property contains low-level system information captured from system. This is system data type (non-Delphi). It's specific to operating system.

Tip. It's not recommended to use this property. Use other properties of TEurekaExceptionInfo class, which exposes exception information extracted from this property.

TEurekaExceptionInfo.ExceptionThreadID

Exception Thread ID (original exception's thread).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

ID of thread. It identificates a thread that has originally raised the exception.

Remarks.

This value indicates exception thread. This value never changes once set.

TEurekaExceptionInfo.Expected

Indicates type of exception (expected).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is expected exception.

False - this is normal/typical exception.

Remarks.

This property indicates type of exception - expected or not.

Exceptions that do not represent a bug in your code are called "expected exceptions". You can mark any exception as expected via various methods. Please see chapter 8 for examples of each method.

You can set the .ExpectedContext (appendix D, TEurekaExceptionInfo.ExpectedContext) or .ExpectedURL (appendix D, TEurekaExceptionInfo.ExpectedContext) properties to set the Expected property to True.

When EurekaLog processes expected exception: it disables creation of bug report, send and restart features, as well as showing technical details (call stack, etc.). Basically, processing of expected exception will only show the exception message to the user and nothing else.

TEurekaExceptionInfo.ExpectedContext

Help context number for exception.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Integer for HelpContext. Must be a valid ID of help topic inside help file for your application.

Remarks.

Contains help context number. Initially empty. You can set this number to point an existing topic of your help file.

When this property is set, exception is considered to be "known" (expected). The help button will be displayed in dialogs, which will open help file of your application with specified topic ID.

Expected exceptions are handled by EurekaLog, but behave differently. They can not be send to developers and do not generate bug reports, there will be no restart/terminate options, etc. In other words, expected exception are handled as just "error dialogs" with no diagnostic/recovery.

You can set exception as expected (as well as set this property) by using RaiseExpected (appendix A) routine.

Tip. This property is used by "Help" button in dialogs. Setting this property will force "Help" button to appear.

Important. Altering this property will alter way of handling this exception by EurekaLog.

TEurekaExceptionInfo.ExpectedURL

Exception URL.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Arbitrary URL to any resource (resource is expected to describe this exception).

Remarks.

The Value section describes a URL to information about the exception. The Remarks section mistakenly describes a numeric help context; that sentence is not a declaration of ExpectedURL and must not be used to infer a numeric type.

When this property is set, exception is considered to be "known" (expected).

Expected exceptions are handled by EurekaLog, but behave differently. They can not be send to developers and do not generate bug reports.

You can set exception as expected (as well as set this property) by using RaiseExpected (appendix A) routine.

Tip. This property is displayed by console dialog.

Important. Altering this property will alter way of handling this exception by EurekaLog.

TEurekaExceptionInfo.Handled

Indicates type of exception (handled).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is handled exception.

False - this is unhandled exception.

Remarks.

This property indicates type of exception - handled or not. Handled = False on creation and may become True later, when handling code will run.

Unhandled exception is exception which wasn't catched by your code. Such exceptions are processed by EurekaLog.

Handled exception is exception which was catched by your application. Such exceptions are processed by your code and EurekaLog is not invoked for them (by default). You can alter this behavior by using "catch handled exception" option in EurekaLog project options.

TEurekaExceptionInfo.Handler

Exception handler name.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

One of atXYZ constants (such as atVCL, atThread, atDataSnap, etc.).

Remarks.

This property indicates which handler is processing exception. For example, you can use this property in your event handlers to change dialog from MS Classic to none - if exception was catched by atThread or atDataSnap (as opposed to atVCL).

Default value is atGeneric.

TEurekaExceptionInfo.Info

Returns low-level exception information.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Low-level exception information.

Remarks.

Low-level information that was captured for this exception.

Tip. Do not use this property. Other properties of TEurekaExceptionInfo class exposes exception information extracted from this property. Use other properties of TEurekaExceptionInfo class to get exception information.

TEurekaExceptionInfo.InitializationException

Indicates type of exception (initialization).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is initialization/finalization exception.

False - this is normal exception.

Remarks.

This property indicates type of exception - initialization/finalization or not.

Initialization/finalization exception is an exception inside initialization/finalization code blocks of unit. Such exceptions are always unhandled.

TEurekaExceptionInfo.InnerException

Inner exception.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Exception information for inner exception. If no such exception exists - returns nil.

Remarks.

Read the value of the InnerException property to obtain the inner exception. If there are no exceptions that triggered the current one, InnerException returns nil; otherwise InnerException returns the inner exception that triggered a specific exception.

Tip. Unlike RTL's InnerException, EurekaLog's InnerException is always captured.

TEurekaExceptionInfo.LastSystemErrorCode

Value of GetLastError function when exception was raised.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

System error code returned by the GetLastError function.

Remarks.

EurekaLog saves value of the GetLastError function into this property when exception was thrown.

TEurekaExceptionInfo.Module

Exception module.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

HINST/HMODULE of executable module containing exception address (appendix D, TEurekaExceptionInfo.Address). Can be 0 if exception was raised in dynamically generated code.

Remarks.

Handle of the exception module (if present).

Note. Exception module may be unloaded after exception raising, so this value will hold old handle which is no longer valid.

Use ModuleName (appendix D, TEurekaExceptionInfo.ModuleName)/ ModuleVersion (appendix D, TEurekaExceptionInfo.ModuleVersion) properties to get module information.

TEurekaExceptionInfo.ModuleName

Exception module name.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Full file name of executable module containing exception address (appendix D, TEurekaExceptionInfo.Address). Can be '' (empty string) if exception was raised in dynamically generated code.

Remarks.

File name of the exception module (if present).

Since exception module may be unloaded after exception raising, this value holds cached module name, so it can be used at any time.

TEurekaExceptionInfo.ModuleVersion

Version of exception module.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Version information of executable module containing exception address (appendix D, TEurekaExceptionInfo.Address). Can be '' (empty string) if exception was raised in dynamically generated code.

Remarks.

Version information of the exception module (if present).

Since exception module may be unloaded after exception raising, this value holds cached version info, so it can be used at any time.

TEurekaExceptionInfo.Options

EurekaLog options for this exception.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Actual EurekaLog options for this exception.

Remarks.

Each exception gets its own TEurekaExceptionInfo object which describes this exception. Each TEurekaExceptionInfo object has Options property of type TEurekaModuleOptions. Therefore, each exception has its own EurekaLog options.

Options are isolated and do not depend on CurrentEurekaLogOptions and options of other exceptions. I.e. any change to Options property will be visible only for that exception and nowhere else.

Initially options equal to CurrentEurekaLogOptions, but they may be changed during exception processing.

Other objects (like dialog, sender, log builder, etc.) share this Options property. I.e. all processing code uses the same object instance, so changes in, say, event handler will be visible for all other objects (dialogs, log builder, etc.).

TEurekaExceptionInfo.Processed

Indicates type of exception (processed).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is processed exception.

False - this is unprocessed exception.

Remarks.

This property indicates type of exception - processed or not.

Processed exception is an exception that was processed (i.e. handled) by EurekaLog. Each exception is initially unprocessed. It becomes processed when EurekaLog handles it via ExceptionManager (appendix A). Handle (appendix D, TExceptionManager.Handle) and ProcessException. Once exception is processed, it's no longer invokes EurekaLog and can not be handled again. Setting Processed to True will exclude exception from EurekaLog's processing.

TEurekaExceptionInfo.Reader

Exception information reader.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Exception reader object used to extract information from exception low-level records.

Remarks.

This is instance of so-called "exception information reader" class (which is a child class for TExceptionReader). This object was used to fill properties of TEurekaExceptionInfo instance.

EurekaLog has several different readers which are able to extract information from Delphi exceptions, C++ Builder exceptions, hardware exceptions. It's possible to add more extractor classes (for example, to support Visual C++ exceptions).

Tip. It's not recommended to use this property. Use other properties of the TEurekaExceptionInfo class.

TEurekaExceptionInfo.ReproduceText

Steps to reproduce.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Text for steps to reproduce as entered by user.

Remarks.

This value is initially empty and it's set by MS Classic or EurekaLog dialogs when user enters non-empty "steps to reproduce".

TEurekaExceptionInfo.SafeCallExpt

Indicates type of exception (safecall).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is safecall exception.

False - this is normal exception.

Remarks.

This property indicates type of exception - safecall or not.

Safecall exception is an exception inside safecall method. Such exceptions are handled by SafeCallException method of called object (that's why safecall exceptions are always handled).

TEurekaExceptionInfo.Secondary

Indicates type of exception (secondary).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is secondary exception.

False - this is normal/typical/first exception.

Remarks.

This property indicates type of exception - secondary or not.

Secondary exception is an exception which was raised (thrown) when another exception is being handled. For example, your code raises exception, EurekaLog shows dialog about your exception. Then your code throws another exception, while dialog is still being displayed. That second exception will be secondary exception.

EurekaLog can be configured to behave differently for secondary exceptions.

TEurekaExceptionInfo.StackDump

Stack dump.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Pointer to stack dump.

Remarks.

Stack dump is a block of RAW memory. It's copied from CPU stack from StackPoint (appendix D, TEurekaExceptionInfo.StackPoint) position. It's size equals SizeOf(Pointer) X EStackDumpDepth (EConsts unit). I.e. 4 x 16 = 64 bytes for x86-32, or 8 x 16 = 128 bytes for x86-64. No padding is used.

TEurekaExceptionInfo.StackPoint

Indicates current position of stack.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Pointer to stack's current position of exception thread.

Remarks.

This property contains pointer to current position of CPU stack for the exception thread. It is usually ESP/EBP register.

This value is used to capture dump of CPU stack. It's also listed in bug report on CPU page as "STK" value.

Tip. It's not recommended to use this property.

TEurekaExceptionInfo.StackTop

Indicates top of stack.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Pointer to top of stack of exception thread.

Remarks.

This property contains pointer to top of CPU stack for the exception thread. "Top of the stack" is stack's highest available address.

Tip. It's not recommended to use this property.

TEurekaExceptionInfo.SynchronizeException

Indicates type of exception (synchronize).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this is synchronize exception.

False - this is normal exception.

Remarks.

This property indicates type of exception - synchronized or not.

Synchronized exception is an exception inside Synchronize method. Such exceptions are handled by Synchronize routine itself (that's why synchronized exceptions are always handled). Synchronized exceptions are re-raised in another thread.

TEurekaExceptionInfo.ThreadException

Indicates type of exception (thread).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True - this exception was raised inside a background thread and it is captured to be re-raised later (in the main thread).

False - this is normal exception.

Remarks.

This property indicates type of exception - thread exception or not.

Thread exception is exception inside thread which is captured by thread wrapper (such as TThread or TOmniTask). Such exceptions are handled by the wrapper by saving exception into "FatalException" property. Such exceptions are not handled inside thread.

This property is always True when SynchronizeException property is True.

TEurekaExceptionInfo.ThreadID

Thread ID (actual exception's thread).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

ID of thread. It identificates a thread that has raised or re-raised the exception.

Remarks.

This value indicates exception thread. The same code may be run in multiple threads. This property can be used to distinguish between same exceptions in different threads.

Warning. This value identificates a thread that has raised or re-raised the exception. In other words, if you take exception from a background thread (TThread) and re-raise it in the main thread - this property will return ID of the main thread, since the main thread has re-raised the exception. If you want to know which thread has originally raised the exception - use the .ExceptionThreadID (appendix D, TEurekaExceptionInfo.ExceptionThreadID) property instead.

Warning. .ThreadID does not always match GetCurrentThreadID function. For example, a stack overflow exception will have .ThreadID set to the thread which has raised the stack overflow exception. However, the GetCurrentThreadID function will return a different ID, because all stack overflow exceptions are being handled in a standalone service background thread.

Tip. In most cases, but not always: .ThreadID = .ExceptionThreadID = GetCurrentThreadID.

TEurekaExceptionInfo.Time

Exception time.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Date-time of exception raising. Local time.

Remarks.

Indicates when exception was raised.

TEurekaExceptionInfo.ToString

String representation of exception information.

public
function ToString: String;
override;

Return value.

Exception message and compact call stack.

Remarks.

Use this property to get simple human-redable description of the exception.

Tip. Use ELogBuilder (appendix C) and/or ESysInfo (appendix C) units to build more advanced logs.

TEurekaExceptionInfo.UnhandledExceptionNumber

Number of unhandled exceptions.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Global unhandled exception counter for this exception.

Remarks.

EurekaLog keeps global exception counter. Each time an exception is handled by EurekaLog - this counter is increased and its current value is saved to this property (and in bug report as "Exception/Count" field).

This property is updated when exception is handled by EurekaLog. It's not set until that moment.

EExceptionManager

TExceptionManager

Exception manager class.

TExceptionManager = class(TCheckedInterfacedObject, IInterface, IDLLExceptionManagerV1, IStackTracingSupportV1, IMemoryChecksV1, IThreadsSupportV1, IDestroyNotify, IInitOptions);

Remarks.

This is class for exception manager object.

Exception manager is central control center for exceptions. Exception manager collects information about each exception, store information, invokes dialogs and sending, etc.

Caution!

Do not create instances of this class manually. Use ExceptionManager (appendix A) or TExceptionManager.Instance (appendix D) to access TExceptionManager class.

TExceptionManager.ClearThreadExceptions

Clears last occurred exception in current thread.

public
procedure ClearThreadExceptions;
overload;

Remarks.

This function unregisters last occured exception in current thread. This function deletes exception information about last occured exception in current thread.

After calling this function:

LastThreadException (appendix D, TExceptionManager.LastThreadException) will return nil.
ShowLastExceptionData (appendix D, TExceptionManager.ShowLastExceptionData) will do nothing (return srNoExceptionInfo (appendix B, TSendResult.srNoExceptionInfo) code).
Corresponding TEurekaExceptionInfo (appendix D) object will be destroyed.

Note. This method affects current thread only. Other threads are unaffected. Calling this function is thread-safe.

TExceptionManager.ExceptionCount

Count of all exceptions.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Count of all catched exceptions since application start. This value is >= 0 and always increasing as time progresses. This value never decreases.

Remarks.

Every time when exception manager founds new exception - this value is increased by 1. Actual counter is also saved to exception's information (see TEurekaExceptionInfo (appendix D).ExceptionNumber (appendix D, TEurekaExceptionInfo.ExceptionNumber)).

This value holds count of discovered exceptions regardless of their kind (handled or not). If you want to get number of actually processed exceptions - use UnhandledExceptionCount (appendix D, TExceptionManager.UnhandledExceptionCount) property.

Tip. This value does NOT represent count of active exceptions.

TExceptionManager.Handle

Handles (processes) specified exception.

public
function Handle(
  const AInfo: TEurekaExceptionInfo;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;
function Handle(
  const AInfo: TExceptionData;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;
function Handle(
  const AInfo: Pointer;
  const AAddr: Pointer = nil;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;
function Handle(
  const AInfo: TObject;
  const AAddr: Pointer = nil;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;
function Handle(
  const AInfo: Windows.TExceptionRecord;
  const AContext: PContext = nil;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;
function Handle(
  const AInfo: TExceptionPointers;
  const AHandled: Boolean = False;
  const ARespectActivation: Boolean = True
): TResponse; overload;

Parameters.

AInfo [in] — Exception object, exception information, exception data, or any other information which identifies exception (there are multiple overloads variants of the same Info method). If this value is not specified ( nil) - then method will return srNoExceptionInfo (appendix B, TSendResult.srNoExceptionInfo).
AAddr [in, optional] — Exception address. Typically this is ExceptAddr value. This argument is present not in all overloaded methods.
AContext [in, optional] — Pointer to low-level CPU information. This information will be used for creation of new information. It's not used for identification purposes.
AHandled [in, optional] — True - this exception is handled. False - this exception is unhandled.

Exception information will be modified with this value. Handled/Unhandled sign is used for two different kinds of exception processing. "Handled" exceptions are not processed by default.

ARespectActivation [in, optional] — True (default) - check the current status of EurekaLog. If no EurekaLog is enabled - return srRestart, otherwise (EurekaLog is enabled) - do the usual work.

False - always process the exceptions even if EurekaLog is not active.

Return value.

Result of exception processing. This record hold multiple fields with information - code, messages, etc. See TResponse (appendix B) for more information.

Remarks.

This method performs processing of exception - that is: dialog, bug report saving, sending.

This function is a wrapper for ProcessException function, except it also updates exception manager state:

This method invokes OnExceptionNotify (appendix B, TELEvExceptionNotifyMeth) event.
Exception filters are launched (if present).
Statistics for auto-restart feature is calculated.
ProcessException function is called to perform actual processing.
This method is also handles all exceptions during processing, converting them to TResponse value.

Important. It's recommended to use Handle method of exception manager instead of calling ProcessException directly.

Important. Handle requires exception information with an actual captured call stack. Merely constructing an exception object is not the same as raising it: calling Handle for an object without that information returns srNoExceptionInfo (appendix B, TSendResult.srNoExceptionInfo), rather than performing normal report/dialog/sending processing. Use the exception-information and reporting workflow in chapter 8 when creating a report programmatically; do not treat an unraised Exception.Create result as a captured exception.

TExceptionManager.Info

Returns information about exception.

public
function Info(
  const AInfo: Pointer;
  const AAddr: Pointer = nil;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  const AInfo: TObject;
  const AAddr: Pointer = nil;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  const AInfo: TObject;
  const AExceptionRecord: Windows.TExceptionRecord;
  const AContext: PContext = nil;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  const AInfo: TObject;
  const AEP: TExceptionPointers;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  var AInfo: TExceptionData;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  const AInfo: Windows.TExceptionRecord;
  const AContext: PContext = nil;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;
function Info(
  const AInfo: TExceptionPointers;
  const AForcedNew: Boolean = False;
  const ARespectActivation: Boolean = True;
  const ADoNotCreateNew: Boolean = False
): TEurekaExceptionInfo; overload;

Parameters.

AInfo [in] — Exception object, exception information, exception data, or any other information which identifies exception (there are multiple overloads variants of the same Info method). If this value is not specified ( nil) - then nil will be returned from the method.
AAddr [in, optional] — Exception address. Typically this is ExceptAddr value. This argument is present not in all overloaded methods.
AContext [in, optional] — Pointer to low-level CPU information. This information will be used for creation of new information. It's not used for identification purposes.
AForcedNew [in, optional] — False (default) - standard behaviour: try to locate already created info, reate new information only when no existing info is found.

True - always create new information instance. It's recommended don't use this value unless you're 100% sure that your exception is new (just created). Value of True is used by exception hooks.

ARespectActivation [in, optional] — True (default) - check the current status of EurekaLog. If no EurekaLog is enabled - return nil, otherwise (EurekaLog is enabled) - do the usual work.

False - always retrieve information even if EurekaLog is not active.

Return value.

Information about specified exception or nil if information doesn't exist.

TExceptionManager.Instance

Returns singleton instance for TExceptionManager class.

public
class function Instance: TExceptionManager;

Value.

Instance of exception manager.

Remarks.

This is global access method for exception manager. Use it to invoke routines of exception manager. Do not create instances of TExceptionManager class.

Exception manager instance is created and deleted automatically. You don't need to manually control life-time of this object.

See TExceptionManager (appendix D) for more information.

Note. This method is the same as ExceptionManager (appendix A) function.

TExceptionManager.LastThreadException

Returns last occurred exception in current thread.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Information about most recent raised exception for active thread.

Remarks.

Returns information about last raised exception in current thread. You can use this property to obtain information about last exception.

If you want to get information about arbitrary exception object (it's not needed to be the last raised, it even may be already handled and processed) - then call Info (appendix D, TExceptionManager.Info) method.

Tip. This method is EurekaLog-equivalent of a ExceptObject function.

Note. This method returns information about current thread only. It won't return information about exceptions in other threads. Calling this method is thread-safe.

TExceptionManager.Mode

Indicate work mode of exception manager.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

State of additional hooks.

Remarks.

Work mode indicate what kind of additional hooks were installed by exception manager. Additional hooks are required for some special features to work. This includes "Catch handled exceptions" and "Handle safecall exceptions" options. This mode doesn't indicate state of primary hooks.

TExceptionManager.Notify

Notifies exception manager about exception.

protected
procedure Notify(
  const AInfo: TEurekaExceptionInfo;
  const ARespectActivation: Boolean = True;
  const AExternalThread: Boolean = False
); overload;
procedure Notify(
  const AInfo: TExceptionData;
  const ARespectActivation: Boolean = True
); overload;
procedure Notify(
  const AInfo: Pointer;
  const AAddr: Pointer = nil;
  const ARespectActivation: Boolean = True
); overload;
procedure Notify(
  const AInfo: TObject;
  const AAddr: Pointer = nil;
  const ARespectActivation: Boolean = True
); overload;
procedure Notify(
  const AInfo: Windows.TExceptionRecord;
  const AContext: PContext = nil;
  const ARespectActivation: Boolean = True
); overload;
procedure Notify(
  const AInfo: TExceptionPointers;
  const ARespectActivation: Boolean = True
); overload;

Parameters.

AInfo [in] — Exception object, exception information, exception data, or any other information which identifies exception (there are multiple overloads variants of the same Info method). If this value is not specified ( nil) - then nil will be returned from the method.
AAddr [in, optional] — Exception address. Typically this is ExceptAddr value. This argument is present not in all overloaded methods.
AContext [in, optional] — Pointer to low-level CPU information. This information will be used for creation of new information. It's not used for identification purposes.
ARespectActivation [in, optional] — True (default) - check the current status of EurekaLog. If no EurekaLog is enabled - return nil, otherwise (EurekaLog is enabled) - do the usual work.

False - always retrieve information even if EurekaLog is not active.

Return value.

Information about specified exception or nil if information can not be created.

Remarks.

Warning. Do not call this method directly! It's called only from hooks to notify exception manager about exceptions.

First, this method retrieves actual exception information via Info method. If no information exists - it will be created.
The method updates counters (exception count (appendix D, TExceptionManager.ExceptionCount))
Updates last exception (appendix D, TExceptionManager.LastThreadException).
Build chained exceptions chain.
Removes obsolete information blocks (deleted/not active exceptions).
Invokes OnRaise (appendix B, TELEvRaiseMeth) event.

TExceptionManager.ShowLastExceptionData

Handles last active exception (if any exists).

public
function ShowLastExceptionData: TResponse;

Return value.

Result of exception processing.

Remarks.

This is the same as:

Handle (appendix D, TExceptionManager.Handle)(LastThreadException (appendix D, TExceptionManager.LastThreadException));

If there is no active exception - srNoExceptionInfo (appendix B, TSendResult.srNoExceptionInfo) code will be returned.

This action usually means displaying error dialog, generating/saving bug report, sending report, etc.

This method is called from installed hooks. Hooks for such methods as TApplication.ShowException.

Tip. This method is EurekaLog-equivalent of TApplication.HandleException method.

TExceptionManager.StandardEurekaError

Invokes EurekaLog without raising exception.

public
function StandardEurekaError(
  const Error: String;
  const AOptions: TEurekaModuleOptions = nil
): TResponse;

Parameters.

Error [in] — Error message to display in dialogs and report.
AOptions [in, optional] — EurekaLog options for this operation. Most important options are: csoShowRTLThreads, csoShowWindowsThreads and csoShowELThreads properties.

Return value.

Result of processing. See Handle (appendix D, TExceptionManager.Handle) and TResponse (appendix B) for more information.

Remarks.

This function creates exception of EEurekaLogGeneralError (appendix D) class and passes it to Handle (appendix D, TExceptionManager.Handle) method.

Use this method to invoke EurekaLog (i.e. show dialog, save report, send report) without actually raising exception. You can also setup exception filters or event handlers to alter processing behaviour of this "exception". Use EEurekaLogGeneralError class from EBase unit to differ this exception from typical exceptions.

The advantage of this function over usual raising method is that no exception will be raised at all (even though exception object will be created). Thus, you will save some performance and you also will not be disturbed by exception notification dialog from debugger.

TExceptionManager.StandardEurekaNotify

Handle a specific exception.

public
function StandardEurekaNotify(
  const Obj: TObject;
  const Addr: Pointer = nil;
  const AOptions: TEurekaModuleOptions = nil
): TResponse;

Parameters.

Obj [in] — Exception object. Can be value from ExceptObject function.
Addr [in, optional] — Exception address. Can be value from ExceptAddr function.
AOptions [in, optional] — EurekaLog options for this operation. Most important options are: csoShowRTLThreads, csoShowWindowsThreads and csoShowELThreads properties.

Return value.

Result of exception's processing. See Handle (appendix D, TExceptionManager.Handle) and TResponse (appendix B) for more information.

Remarks.

This is a simple combination of Info (appendix D, TExceptionManager.Info) and Handle (appendix D, TExceptionManager.Handle) methods. This method is a tool for adding EurekaLog to unsupported applications types. You can call this method from your custom exception handler to invoke EurekaLog's processing.

This method is similar to ShowLastExceptionData (appendix D, TExceptionManager.ShowLastExceptionData), except it allows to specify exception object.

Tip. The diffrence between this method and the Handle (appendix D, TExceptionManager.Handle) method is this: Handle method will do nothing for non-raised exceptions. StandardEurekaNotify will create call stack for non-raised exceptions.

TExceptionManager.UnhandledExceptionCount

Count of all processed exceptions.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Count of all exceptions that were processed since application start. This value is >= 0 and always increasing as time progresses. This value never decreases.

Remarks.

Every time when exception manager handles exception (i.e. shows dialog, saves bug report, etc.) - this value is increased by 1. Actual counter is also saved to exception's information (see TEurekaExceptionInfo (appendix D).UnhandledExceptionNumber (appendix D, TEurekaExceptionInfo.UnhandledExceptionNumber)).

This value holds count of processed exceptions, it's always less or equal to ExceptionCount (appendix D, TExceptionManager.ExceptionCount) property.

Tip. If you set your application to terminate or restart after the very first unhandled exception - then this value will be 0 all the time. And it will be 1 during exception processing, but you will not see 2 here.

Tip. This value does NOT represent count of active exceptions.

EFreeze

TFreezeThread

Base class for freeze detection threads.

TFreezeThread = class(TThreadEx);

Remarks.

This is an abstract class to be used as base class when implementing background freeze detection thread. Override the Execute (appendix D, TFreezeThread.Execute) method and implement your own freeze detection logic. Call RaiseFreezeException (appendix A) once you detect freeze/hang/deadlock.

Note. FreezeThreadClass (appendix C) variable determinates which class EurekaLog should use. Use InitCheckFreeze (appendix A) to re-initialize freeze detection if it is already running.

TFreezeThread.ChecksPaused

Indicates whether freeze checks are disabled.

protected
function ChecksPaused: Boolean;

Return value.

True - freeze checks are disabled; False - freeze checks are enabled.

Remarks.

The thread's Execute (appendix D, TFreezeThread.Execute) method and any methods that Execute calls should check ChecksPaused periodically and do nothing when it's True. The PauseFreezeCheck (appendix A) procedure sets the ChecksPaused property to True.

TFreezeThread.Execute

Implements actual freeze detection code.

protected
procedure Execute;
override;

Remarks.

Override Execute and insert the code that should be executed when the thread runs. Execute is responsible for checking the value of the Terminated property to determine if the thread needs to exit, and for checking the value of ChecksPaused (appendix D, TFreezeThread.ChecksPaused) property to determinate if freeze detection checks are disabled.

Important. Do not forget to call inherited Execute implementation in your own overridden implementations of Execute.

TFreezeThread.FreezeTimeout

Freeze timeout from InitCheckFreeze (appendix A).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Contract unavailable: no additional public declaration, usage preconditions, or member-behavior contract is specified here. Do not infer support beyond the documented owning type and member description.

TFreezeThread.TargetThreadHandle

Thread handle from InitCheckFreeze (appendix A).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

TFreezeThread.TargetThreadID

Thread ID from InitCheckFreeze (appendix A).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

TFreezeThread.TargetWindow

Window handle from InitCheckFreeze (appendix A).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

TMainThreadFreezeDetectionThread

Thread class to detects hangs in UI thread.

TMainThreadFreezeDetectionThread = class(TFreezeThread);

Remarks.

This thread uses SendMessageTimeout function to detect if main thread is responding on messages.

Note. This freeze detection thread class can be used on any system.

EurekaLog uses this class by default on pre-Vista systems (Windows XP and earlier).

TWCTFreezeDetectionThread

Thread class to detects deadlocks between threads.

TWCTFreezeDetectionThread = class(TFreezeThread);

Remarks.

This thread uses Wait Chain Traversal function to detect deadlocks between two or more EurekaLog-enabled threads.

Note. This freeze detection thread class can be used on Vista+ systems only.

EurekaLog uses this class by default on Vista+ systems (Windows Vista and later).

ELogBuilder

Constructor TBaseLogBuilder.Create

Creates instance of log builder class.

public
constructor Create(
  const AExceptionInfo: TEurekaExceptionInfo
); virtual;

Parameters.

AExceptionInfo [in] — Exception information to build bug report. This information is saved to TBaseLogBuilder.ExceptionInfo (appendix D) property.

Remarks.

This is default constructor for any log builder class.

Note. Creating log builder instance will not generate bug report. Bug report will not be created until TBaseLogBuilder.Report (appendix D) property is accessed. I.e. bug report is created on demand.

TBaseLogBuilder

Base class for log builder.

TBaseLogBuilder = class(TObject);

Remarks.

This is abstract class for any specific log builder. Log builder is a class which is used by EurekaLog to create bug reports from exception information. There is a specific sub-class inherited from this abstract class which is used by default: TLogBuilder (appendix D).

Another build-in log builder classes are TXMLLogBuilder (appendix D), TJSONLogBuilder (appendix D) and TDummyLogBuilder (appendix D).

Any other log builder class should be defined by user. Any specific sub-class must implement BuildReport method.

Normally you don't need to create instances of this class manually. See BuildBugReport (appendix A).

Note. Bug report is a simple multi-line text. Multi-files bug reports (ELP/ZIP) are created by dialog class (appendix D, TBaseDialog).

TBaseLogBuilder.BuildReport

Builds bug report.

protected
function BuildReport: String;
virtual;
abstract;

Return value.

Textual representation of bug report.

Remarks.

This is abstract method which generates actual bug report from exception information. Exception information can be obtained via TBaseLogBuilder.ExceptionInfo (appendix D) property. TBaseLogBuilder also has some other useful properties for bug report generation.

Any non-abstract sub-class of TBaseLogBuilder class should implement this method.

Caution!

Do not call this method directly. Call TBaseLogBuilder.ToString (appendix D) method or TBaseLogBuilder.Report (appendix D) property instead.

Note. Usually this method is called only once per class instance. TBaseLogBuilder uses caching of bug report for performance reasons. See also: TBaseLogBuilder.Refresh (appendix D)

TBaseLogBuilder.CallStack

Call stack.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Call stack of exception. Default is TBaseLogBuilder.ExceptionInfo (appendix D).CallStack (appendix D, TEurekaExceptionInfo.CallStack).

Remarks.

This property can be used by TBaseLogBuilder.BuildReport (appendix D) method. This property can be overriden by sub-classes to customize bug report content without affecting exception information.

TBaseLogBuilder.CustomFields

Custom fields for Options.soCustomData.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Set of name-value pairs to be used as custom data in bug reports.

Remarks.

This property can be used to specify custom data for bug report. Typically you fill this property right after creation of log builder instance and before accessing TBaseLogBuilder.Report (appendix D) property.

Tip. Name-value pairs can be easily specified by using TStrings.Values property.

Note. Altering CustomFields property will not refresh bug report automatically. You need to call TBaseLogBuilder.Refresh (appendix D) method to reflect changes.

TBaseLogBuilder.ExceptionInfo

Exception information.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Exception information to build bug report.

Remarks.

This is exception information object which was passed to constructor (appendix D, Constructor TBaseLogBuilder.Create). TBaseLogBuilder.BuildReport (appendix D) method can use this property to gather information about exception.

Note. There are TBaseLogBuilder.CallStack (appendix D) and TBaseLogBuilder.Options (appendix D) properties which should be used instead of TBaseLogBuilder.ExceptionInfo.CallStack (appendix D, TEurekaExceptionInfo.CallStack) and TBaseLogBuilder.ExceptionInfo.Options (appendix D, TEurekaExceptionInfo.Options) property. TBaseLogBuilder.CallStack (appendix D) and TBaseLogBuilder.Options (appendix D) properties can be overriden by sub-classes to customize bug report content without affecting exception information.

TBaseLogBuilder.FBuilded

Specifies if bug report was created or not.

protected
  FBuilded: Boolean;

Value.

True: bug report was created, TBaseLogBuilder.Report (appendix D) property will return cached created bug report from internal field. False: bug report was not created, TBaseLogBuilder.Report (appendix D) property will generate new report and cache it into internal field.

Remarks.

This flag is used by caching. Bug report is not created each time TBaseLogBuilder.Report (appendix D) property is accessed for performance reasons. If you want to explicitly regenerate bug report (for example, to reflect latest changes in exception information or environment) - use TBaseLogBuilder.Refresh (appendix D) method.

Note. Caching is performed automatically. You don't need to do anything special in TBaseLogBuilder.BuildReport (appendix D) method. TBaseLogBuilder class will automatically cache bug report for later use.

TBaseLogBuilder.Options

EurekaLog options.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Call stack of exception. Default is TBaseLogBuilder.ExceptionInfo (appendix D).Options (appendix D, TEurekaExceptionInfo.Options).

Remarks.

This property can be used by TBaseLogBuilder.BuildReport (appendix D) method. This property can be overriden by sub-classes to customize bug report content without affecting exception information.

TBaseLogBuilder.Refresh

Refreshes (i.e. recreates) bug report.

protected
procedure Refresh;
virtual;

Remarks.

Sets TBaseLogBuilder.FBuilded (appendix D) to False, so next access to TBaseLogBuilder.Report (appendix D) property will generate new bug report. Use this method to reflect changes in exception or environment information (for example, user e-mail was changed in dialog).

TBaseLogBuilder.Report

Generates and returns bug report.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Textual representation of bug report.

Remarks.

Call this property to generate and retrieve bug report for exception information which was specified in constructor (appendix D, Constructor TBaseLogBuilder.Create) of log builder instance. Specified exception information can be checked by reading TBaseLogBuilder.ExceptionInfo (appendix D) property.

Note. Actual bug report generation takes place in TBaseLogBuilder.BuildReport (appendix D) method.

TBaseLogBuilder.ToString

Returns textual representation of class instance.

public
function ToString: String;
override;

Return value.

Value of TBaseLogBuilder.Report (appendix D) property.

Remarks.

Returns bug report. Calling this method is the same as accessing TBaseLogBuilder.Report (appendix D) property.

TDummyLogBuilder

Dummy log builder class.

TDummyLogBuilder = class(TBaseLogBuilder);

Remarks.

This log builder class can "generate" a pre-made bug report. You can pass arbitrary string to constructor of this class and this string will be returned as bug report. This class can not be used as default log builder class (i.e. via LogBuilderClass (appendix C)) - because there is no way to pass "report string" to alternative constructor), but it is usefull to use already generated bug report in dialogs.

TJSONLogBuilder

JSON EurekaLog 7+ log builder.

TJSONLogBuilder = class(TBaseLogBuilder);

Remarks.

This is log builder class for EurekaLog 7 and above. It is used to save JSON bug reports.

TLogBuilder

Default EurekaLog 7 log builder.

TLogBuilder = class(TBaseLogBuilder);

Remarks.

This is default log builder class for EurekaLog 7 and above. It's used as default value for LogBuilderClass (appendix C) global variable.

There are 3 more build-in log builder classes: TXMLLogBuilder (appendix D), TJSONLogBuilder (appendix D), and TDummyLogBuilder (appendix D).

The plain-text report includes exception information and resolved call-stack details. The selected report options determine which sections and fields are present.

Illustrative example — abbreviated, not a complete report:

Exception:
  Type: Exception
  Message: Synthetic demonstration error
Call Stack Information:
  Module: ExampleApp.exe
  Unit: ExampleUnit
  Procedure/Method: DemonstrationOperation

TXMLLogBuilder

XML EurekaLog 7+ log builder.

TXMLLogBuilder = class(TBaseLogBuilder);

Remarks.

This is log builder class for EurekaLog 7 and above. It is used to save XML bug reports.

ELogging

IEurekaLogger

Interface which holds a single entry in log file.

IEurekaLog(IUnknown)
['{76A72C59-97B1-4561-AE67-67F8B9F67EE8}'];

Remarks.

This interface is returned by various ELog (appendix A) functions. You can use it to alter properties of created log entry.

IEurekaLogger.AddCheckPoint

Same as ELogAddCheckPoint (appendix A) function.

public
procedure AddCheckPoint;

Remarks.

This method duplicates ELogAddCheckPoint (appendix A) function. Please, see ELogAddCheckPoint (appendix A) function for more information.

IEurekaLogger.AddResetSeparator

Same as ELogAddResetSeparator (appendix A) function.

public
procedure AddResetSeparator;

Remarks.

This method duplicates ELogAddResetSeparator (appendix A) function. Please, see ELogAddResetSeparator (appendix A) function for more information.

IEurekaLogger.AddSeparator

Same as ELogAddSeparator (appendix A) function.

public
procedure AddSeparator;

Remarks.

This method duplicates ELogAddSeparator (appendix A) function. Please, see ELogAddSeparator (appendix A) function for more information.

IEurekaLogger.Category

Changes category of the log entry.

public
function Category(
  const ACategoryName: String
): IEurekaLogger;

Parameters.

ACategoryName

New category to be set. This is an arbitraty string.

Return value.

A modified log entry with new category set up.

Remarks.

This method changes category of the log entry. You may use it to group log entries into different categories. EurekaLog's categories start with 'EurekaLog'.

IEurekaLogger.Color

Changes color of the log entry.

public
function Color(
  const AColor: DWORD
): IEurekaLogger;

Parameters.

AColor

New color to be set.

Return value.

A modified log entry with new color set up.

Remarks.

This method changes color of the log entry. You may use it to paint log entries in different colors. Default is clWhite.

IEurekaLogger.Details

Changes details of the log entry.

public
function Details(
  const ADetails: String
): IEurekaLogger;

Parameters.

ADetails

New details to be set.

Return value.

A modified log entry with new details set up.

Remarks.

This method changes details of the log entry. Usually you do not need to call this.

IEurekaLogger.Enter

Same as ELogEnter (appendix A) function.

public
function Enter(
  const AFuncName: String = ''
): IEurekaLoggerParams; overload;
function Enter(
  const ASelf: TObject;
  const AMethodName: String = ''
): IEurekaLoggerParams; overload;
function Enter(
  const ASelf: TClass;
  const AMethodName: String = ''
): IEurekaLoggerParams; overload;

Remarks.

This method duplicates ELogEnter (appendix A) function. Please, see ELogEnter (appendix A) function for more information.

Parameter detail unavailable: no public parameter-by-parameter contract is specified beyond the declaration and the behavior described here. Parameter names and defaults alone are not additional behavioral guarantees.

IEurekaLogger.FontColor

Changes font color of the log entry.

public
function FontColor(
  const AColor: DWORD
): IEurekaLogger;

Parameters.

AColor

New color to be set.

Return value.

A modified log entry with new font color set up.

Remarks.

This method changes font color of the log entry. You may use it to paint log entries in different colors. Default is clBlack.

IEurekaLogger.Kind

Changes kind of the log entry.

public
function Kind(
  const AMsgType: TLogMsgType
): IEurekaLogger;

Parameters.

AMsgType

New kind to be set.

Return value.

A modified log entry with new kind set up.

Remarks.

This method changes kind of the log entry. Usually you do not need to call this.

IEurekaLogger.Log

Same as ELog (appendix A) function.

public
function Log(
  const AMsg: String
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: String
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Char
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Integer
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Word
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: LongWord;
  const AAsHex: Boolean = False
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: UInt64;
  const AAsHex: Boolean = False
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Int64
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Extended;
  const ADigits: Integer = 2
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: Boolean
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TPoint
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TSmallPoint
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TRect
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TGUID
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TObject
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TExceptionPointers
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TExceptionRecord
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TContext
): IEurekaLogger; overload;
function Log(
  const AMsg: String;
  const AValue: TResponse
): IEurekaLogger; overload;

Remarks.

This method duplicates ELog (appendix A) function. Please, see ELog (appendix A) function for more information.

IEurekaLogger.LogAssigned

Same as ELogAssigned (appendix A) function.

public
function LogAssigned(
  const AMsg: String;
  const AValue: TObject
): IEurekaLogger; overload;

Remarks.

This method duplicates ELogAssigned (appendix A) function. Please, see ELogAssigned (appendix A) function for more information.

IEurekaLogger.LogAssignedPtr

Same as ELogAssignedPtr (appendix A) function.

public
function LogAssignedPtr(
  const AMsg: String;
  const AValue: Pointer
): IEurekaLogger;

Remarks.

This method duplicates ELogAssignedPtr (appendix A) function. Please, see ELogAssignedPtr (appendix A) function for more information.

IEurekaLogger.LogCurrency

Same as ELogCurrency (appendix A) function.

public
function LogCurrency(
  const AMsg: String;
  const AValue: Currency
): IEurekaLogger;

Remarks.

This method duplicates ELogCurrency (appendix A) function. Please, see ELogCurrency (appendix A) function for more information.

IEurekaLogger.LogDateTime

Same as ELogDateTime (appendix A) function.

public
function LogDateTime(
  const AMsg: String;
  const AValue: TDateTime
): IEurekaLogger;

Remarks.

This method duplicates ELogDateTime function. Please, see ELogDateTime (appendix A) function for more information.

IEurekaLogger.LogError

Same as ELogError (appendix A) function.

public
function LogError(
  const AMsg: String
): IEurekaLogger;

Remarks.

This method duplicates ELogError (appendix A) function. Please, see ELogError (appendix A) function for more information.

IEurekaLogger.LogException

Same as ELogException (appendix A) function.

public
function LogException(
  const E: TObject;
  const AMsg: String = ''
): IEurekaLogger;

Remarks.

This method duplicates ELogException (appendix A) function. Please, see ELogException (appendix A) function for more information.

IEurekaLogger.LogIf

Same as ELogIf (appendix A) function.

public
function LogIf(
  const AExpression: Boolean;
  const AMsg: String
): IEurekaLogger; overload;
function LogIf(
  const AExpression: Boolean;
  const AMsg: String;
  const AValue: String
): IEurekaLogger; overload;
function LogIf(
  const AExpression: Boolean;
  const AMsg: String;
  const AValue: Integer
): IEurekaLogger; overload;
function LogIf(
  const AExpression: Boolean;
  const AMsg: String;
  const AValue: TObject
): IEurekaLogger; overload;

Remarks.

This method duplicates ELogIf (appendix A) function. Please, see ELogIf (appendix A) function for more information.

IEurekaLogger.LogIfDateTime

Same as ELogIfDateTime (appendix A) function.

public
function LogIfDateTime(
  const AExpression: Boolean;
  const AMsg: String;
  const AValue: TDateTime
): IEurekaLogger;

Remarks.

This method duplicates ELogIfDateTime (appendix A) function. Please, see ELogIfDateTime (appendix A) function for more information.

IEurekaLogger.LogInterval

Same as ELogInterval (appendix A) function.

public
procedure LogInterval(
  const AMsg: String;
  const AStart: Int64
);

Remarks.

This method duplicates ELogInterval (appendix A) function. Please, see ELogInterval (appendix A) function for more information.

IEurekaLogger.LogMemoryAsHex

Same as ELogMemoryAsHex (appendix A) function.

public
function LogMemoryAsHex(
  const AMsg: String;
  const ABuffer: Pointer;
  ASize: Integer
): IEurekaLogger;

Remarks.

This method duplicates ELogMemoryAsHex (appendix A) function. Please, see ELogMemoryAsHex (appendix A) function for more information.

IEurekaLogger.LogNote

Same as ELogNote (appendix A) function.

public
function LogNote(
  const AMsg: String
): IEurekaLogger;

Remarks.

This method duplicates ELogNote (appendix A) function. Please, see ELogNote (appendix A) function for more information.

IEurekaLogger.LogPointer

Same as ELogPointer (appendix A) function.

public
function LogPointer(
  const AMsg: String;
  const AValue: Pointer
): IEurekaLogger;

Remarks.

This method duplicates ELogPointer (appendix A) function. Please, see ELogPointer (appendix A) function for more information.

IEurekaLogger.LogReminder

Same as ELogReminder (appendix A) function.

public
function LogReminder(
  const AMsg: String
): IEurekaLogger;

Remarks.

This method duplicates ELogReminder (appendix A) function. Please, see ELogReminder (appendix A) function for more information.

IEurekaLogger.LogWarning

Same as ELogWarning (appendix A) function.

public
function LogWarning(
  const AMsg: String
): IEurekaLogger;

Remarks.

This method duplicates ELogWarning (appendix A) function. Please, see ELogWarning (appendix A) function for more information.

IEurekaLogger.LogWindowHandle

Same as ELogWindowHandle (appendix A) function.

public
function LogWindowHandle(
  const AMsg: String;
  const AValue: HWND
): IEurekaLogger;

Remarks.

This method duplicates ELogWindowHandle (appendix A) function. Please, see ELogWindowHandle (appendix A) function for more information.

IEurekaLogger.LogWinError

Same as ELogWinError (appendix A) function.

public
function LogWinError(
  const AMsg: String;
  const ALastError: TSysErrorCode
): IEurekaLogger;

Remarks.

This method duplicates ELogWinError (appendix A) function. Please, see ELogWinError (appendix A) function for more information.

IEurekaLogger.ResetCheckPoint

Same as ELogResetCheckPoint (appendix A) function.

public
procedure ResetCheckPoint;

Remarks.

This method duplicates ELogResetCheckPoint (appendix A) function. Please, see ELogResetCheckPoint (appendix A) function for more information.

IEurekaLoggerParams

Sub-routine log entry.

IEurekaLoggerParams = interface(IEurekaLogger)
['{05A12A38-D3DA-49B6-8935-4427677AD740}'];

Remarks.

A specialized version of IEurekaLogger (appendix D) which allows you to specify additional parameters for current log entry.

Use P (appendix D, IEurekaLoggerParams.P) method to log additional parameter.

Use D (appendix D, IEurekaLoggerParams.D) or C (appendix D, IEurekaLoggerParams.C) to indicate end of parameter list.

Use Ret (appendix D, IEurekaLoggerParams.Ret) to indicate result of sub-routine.

IEurekaLoggerParams.C

Completes logging of function call (collapsed version).

public
function C: IEurekaLoggerParams;

Return value.

Returns log entry. This value could be used to log Result.

Remarks.

Same as D (appendix D, IEurekaLoggerParams.D) method, except function call will appear collapsed in the log.

IEurekaLoggerParams.D

Completes logging of function call.

public
function D: IEurekaLoggerParams;

Return value.

Returns log entry. This value could be used to log Result.

Remarks.

Call this method to indicate that there are no more arguments to the function.

Important. You have to call either D (appendix D, IEurekaLoggerParams.D) or C (appendix D, IEurekaLoggerParams.C) method on the returned IEurekaLoggerParams (appendix D) interface. Otherwise nested log entries may have wrong identation in the resulting log file.

IEurekaLoggerParams.P

Logs argument.

public
function P(
  const AName, AValue: String
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: Int64
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: Pointer
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: TObject
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: Boolean
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: TGUID
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: TDateTime
): IEurekaLoggerParams; overload;
function P(
  const AName: String;
  const AValue: System.UInt64
): IEurekaLoggerParams; overload;

Parameters.

AName

Name of the argument as it appears in source code.

AValue

Value of the argument.

Return value.

Returns log entry with created new argument. This value could be used to add more arguments, to close function call, or to log Result.

Remarks.

Use this method to log one or more arguments to sub-routine.

IEurekaLoggerParams.Ret

Logs return value.

public
procedure Ret(
  const AResult: String
); overload;
procedure Ret(
  const AResult: Integer
); overload;
procedure Ret(
  const AResult: Cardinal
); overload;
procedure Ret(
  const AResult: Int64
); overload;
procedure Ret(
  const AResult: System.UInt64
); overload;
procedure Ret(
  const AResult: TObject
); overload;
procedure Ret(
  const AResult: TResponse
); overload;
procedure Ret(
  const AResult: Boolean
); overload;
procedure Ret(
  const AResult: TDateTime
); overload;
procedure Ret;
overload;

Parameters.

AResult [in] — Value of Result variable.

Remarks.

Use this method to log return value of the sub-routine.

EMapParserBase

TELAbstractMapParser

Base class for .map file parsers.

TELAbstractMapParser = class(TObject);

TELAbstractMapParser.DecodeIdent

Returns humanreadable string from ident, returned by one of MapStringToXYZ functions.

public
class function DecodeIdent(
  const AIdent: String
): String;

Parameters.

AIdent

Result of any MapStringToXYZ method.

TELAbstractMapParser.MapStringToFileName

Reads file name from mapped image of .map file.

public
class function MapStringToFileName(
  AMapString: PELMapString
): String; virtual;

Parameters.

AMapString

A pointer to the beginning of the string to read. Usually points to '(' (see MapStringToStr).

Remarks.

Reads file name from the "Line numbers for Unit1(code.inc) segment .text" section of .map file. See examples.

This method behaves differently on different Delphi versions:

ANSI version of this method returns UTF-8 encoded string.
Unicode version of this method returns UTF-16 encoded string.

TELAbstractMapParser.MapStringToModuleName

Reads unit name from mapped image of .map file.

public
class function MapStringToModuleName(
  AMapString: PELMapString
): String; virtual;

Parameters.

AMapString

A pointer to the beginning of the string to read.

Remarks.

Reads unit name from the "Detailed map of segments" section of .map file. This function strips library name (C++ Builder only) and '.pas' and '.obj' extensions. See examples.

This method behaves differently on different Delphi versions:

ANSI version of this method returns UTF-8 encoded string.
Unicode version of this method returns UTF-16 encoded string.

TELAbstractMapParser.MapStringToStr

Reads string from mapped image of .map-file.

protected
class function MapStringToStr(
  AMapString: PELMapString;
  const AStopOnSpace, AHasRVAColumn, AHasLibColumn: Boolean
): String; virtual;

Parameters.

AMapString

A pointer to the beginning of the string to read.

Remarks.

If AMapString starts with '(' - read string between '()', return data inside '()'.If AMapString starts with any other character: read string until EOL. This method behaves differently on different Delphi versions: ANSI version of this method returns UTF-8 encoded string.Unicode version of this method returns UTF-16 encoded string. Use TELAbstractMapParser.DecodeIdentDecodeIdent to get readable string.

TELAbstractMapParser.PrepareStr

Converts string from .map file to Delphi string.

protected
class function PrepareStr(
  AStart: PELMapString;
  ALen: Integer
): String; virtual;

Parameters.

AStart

Pointer to the begginning of the string.

ALen

Length of string in characters.

Remarks.

ANSI version of this method returns UTF-8 encoded string.

Unicode version of this method returns UTF-16 encoded string.

This is low-level function to convert string from map file to proper encoding. Other routines (MapStringToXYZ) uses this function to prepare result before return.

Use DecodeIdent to get readable string.

ESend

TELUniversalSender

Base class for all send methods.

TELUniversalSender = class(TObject);

Remarks.

This is base abstract class for send methods in EurekaLog. It provides service methods and implements common interface.

Actual (non abstract) send methods are implemented as child sub-classes for this class. Each send method class must be registered via RegisterSender (appendix A) or RegisterSenderFirst (appendix A) functions.

Each child class must implement at least SendMessage method (public), where it must implement sending functionality.

ESendAPIBugZilla

TELTrackerBugZillaSender

Implements API access to BugZilla bug tracker

TELTrackerBugZillaSender = class(TELTrackerJSONSender);

Requirements.

Bug tracker

BugZilla 5.0 or above

Remarks.

BugZilla uses REST JSON API.

ESendAPIExceptionless

TELTrackerExceptionlessSender

Implements API access to Exceptionless bug tracker

TELTrackerExceptionlessSender = class(TELTrackerJSONSender);

Requirements.

Bug tracker

Should support API version 2 (/api/v2/ endpoint)

Remarks.

Exceptionless uses REST JSON API.

ESendAPIFogBugz

TELTrackerFogBugzSender

Implements API access to Fogbugz bug tracker

TELTrackerFogBugzSender = class(TELTrackerSender);

Requirements.

Bug tracker

Fogbugz 6 or above

Remarks.

Fogbugz uses custom XML API.

ESendAPIGitHub

TELTrackerGitHubSender

Implements API access to GitHub bug tracker

TELTrackerGitHubSender = class(TELTrackerJSONSender);

Remarks.

GitHub uses REST JSON API.

ESendAPIGitLab

TELTrackerGitLabSender

Implements API access to GitLab bug tracker

TELTrackerGitLabSender = class(TELTrackerJSONSender);

Remarks.

GitLab uses REST JSON API.

ESendAPIJIRA

TELTrackerJIRASender

Implements API access to JIRA bug tracker

TELTrackerJIRASender = class(TELTrackerJSONSender);

Requirements.

Bug tracker

JIRA Server or JIRA Software Cloud

Remarks.

JIRA uses REST JSON API.

ESendAPIJSON

TELTrackerJSONSender

TELTrackerJSONSender = class(TELTrackerSender);

Remarks.

Implements API access via REST JSON API.

ESendAPIMantis

TELTrackerMantisSender

Implements API access to Mantis bug tracker

TELTrackerMantisSender = class(TELTrackerSender);

Requirements.

Bug tracker

Mantis 1.2.7 or above

Remarks.

Mantis uses SOAP API.

ESendAPIRedmine

TELTrackerRedmineSender

Implements API access to Redmine bug tracker

TELTrackerRedmineSender = class(TELTrackerJSONSender);

Requirements.

Bug tracker

Redmine 2.4 or above (custom fields support is required)

Remarks.

Redmine uses REST JSON API.

ESendAPIYouTrack

TELTrackerYouTrackSender

Implements API access to YouTrack bug tracker

TELTrackerYouTrackSender = class(TELTrackerJSONSender);

Remarks.

YouTrack uses REST JSON API.

ESendMailMAPI

TELMailMAPISender

Implements sending via full MAPI protocol.

TELMailMAPISender = class(TELMailSender);

Remarks.

Implemented by Outlook.

ESendMailShell

TELMailShellSender

Implements sending via mailto: protocol

TELMailShellSender = class(TELMailSender);

Remarks.

Works via ShellExecute.

ESendMailSMAPI

TELMailSimpleMAPISender

Implements sending via Simple MAPI

TELMailSimpleMAPISender = class(TELMailSender);

Remarks.

Works via SMTP stub, can work in cross-bitness.

ESendMailSMTP

TELMailSMTPBaseSender

Base class for SMTP sending.

TELMailSMTPBaseSender = class(TELMailSender);

TELMailSMTPClientSender

Implements sending via SMTP client protocol.

TELMailSMTPClientSender = class(TELMailSMTPBaseSender);

Remarks.

Same as normal e-mail client application.

TELMailSMTPSender

TELMailSMTPSender = class(TELMailSMTPBaseSender);

TELMailSMTPServerSender

Implements sending via SMTP server protocol.

TELMailSMTPServerSender = class(TELMailSMTPBaseSender);

Remarks.

Works by creating a fake e-mail server.

ESendWebFTP

TELFTPSender

Implements sending via FTP uploading.

TELFTPSender = class(TELWebFilesSender);

Remarks.

Application settings must be set up so each bug report has unique file name.

ESendWebHTTP

TELHTTPSender

Implements sending via HTTP posting.

TELHTTPSender = class(TELWebFilesSender);

Remarks.

Requires a custom receiver script or form.

EThreadsManager

TEurekaThreadData

Thread information.

TEurekaThreadData = class(TCheckedInterfacedObject);

Remarks.

This class represents information about running thread in your application. Instances of this class can be acquired via ThreadData (appendix A), AcquireThreadData (appendix A) or ThreadDataEnum (appendix A) functions.

TEurekaThreadData.CallerAddress

Thread creator (address).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A pointer to code which have called CreateThread/BeginThread/TThread.Create. This pointer points somewhere inside a function. It does not point to a function.

Remarks.

This property is used to identify thread's creator. This value is used for building multi-threaded call stacks: it is inserted as a very first (bottom) entry in thread's call stack to indicate thread's creator.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.CallerFunction

Thread creator (description).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A human-readable description of CallerAddress (appendix D, TEurekaThreadData.CallerAddress) property.

Remarks.

This value contains function name identified in CallerAddress (appendix D, TEurekaThreadData.CallerAddress) property. Function name is taken from debug information.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.Handle

Thread handle.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A thread handle with THREAD_QUERY_INFORMATION or THREAD_TERMINATE or SYNCHRONIZE rights or better (usually: full access).

Remarks.

This is opened handle for the thread. The handle is opened on thread's start and is closed on thread's termination. It is not changed during thread's life-time.

Note. This handle is not equal to a return value for CreateThread/BeginThread functions or TThread.Handle property.

Warning. Handle could not be used to identify threads. A single thread may have several different handles opened. Use ID (appendix D, TEurekaThreadData.ID) property to identify threads.

TEurekaThreadData.ID

TID.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Thread ID.

Remarks.

This property stores TID which unique identifies thread in a running application. TID is used as a key for thread lists.

TID is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.IsMainThread

Indicate whenever this thread is main thread.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True for main thread, False for background threads.

Remarks.

This property identifies main thread: that is a thread which TID (thread ID) equals to MainThreadID global variable.

There is only one thread in running application with this property set to True.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.IsRTLThread

Indicate whenever this thread is RTL thread.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True for RTL threads, false for Windows threads.

Remarks.

RTL thread is a thread created with BeginThread function or TThread class. Thread created with CreateThread function is considered to be non-RTL thread: it is a Windows thread.

This property is the opposite for IsWindowsThread (appendix D, TEurekaThreadData.IsWindowsThread) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

Note. Main thread is also considered to be a RTL thread.

TEurekaThreadData.IsWindowsThread

Indicate whenever this thread is Windows thread.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

True for Windows threads, False for RTL threads.

Remarks.

This property is the opposite for IsRTLThread (appendix D, TEurekaThreadData.IsRTLThread) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.Kind

Thread kind (Windows/RTL thread).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Indicates thread kind.

Remarks.

Kind of the thread is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.Name

Thread name (description).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Optional thread name. Thread name (description) is an arbitrary string. Thead name does not have to be unique.

Remarks.

This is an optional thread name, which describes the thread. Threads can be named to simplify debugging. Thread name is an arbitrary string which will be used in bug reports to describe thread. Does not have to be unique. Default value is an empty string.

The name of main thread is always 'Main thread'.

This is a dynamic property which can be changed while thread is running. A common (and recommended) practice is to set thread's name immediately after thread's start and do not change it later.

Use NameThread (appendix A) or NameThreadForDebugging (appendix A) functions to name a thread.

The name (description) of a thread can be set more than once; the most recently set value is used.

TEurekaThreadData.Parameter

Usual thread function's argument.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

RAW pointer argument for StartingAddress (appendix D, TEurekaThreadData.StartingAddress) thread function.

Remarks.

This property contains argument passed to thread function identified by StartingAddress (appendix D, TEurekaThreadData.StartingAddress) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.ParentID

Parent thread ID.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

ID of the thread which has created this thread. 0 for main thread.

Remarks.

This is ID value for parent thread of this thread. A parent thread is a thread which invoked CreateThread/BeginThread function for this thread.

Parent TID is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.Priority

Thread's priority.

public
function Priority: Integer;

Return value.

Value returned by GetThreadPriority function. Possible range is -15..15.

Remarks.

This method retrieves the priority value for the thread. This value, together with the priority class of the thread's process, determines the thread's base-priority level.

The thread's priority level can be any number within -15..+15 range. A well-known standard values are:

-15: (THREAD_PRIORITY_IDLE) Base priority of 1 for usual processes or 16 for REALTIME_PRIORITY_CLASS processes.
-1: (THREAD_PRIORITY_BELOW_NORMAL) Priority 1 point below the priority class.
-2: (THREAD_PRIORITY_LOWEST) Priority 2 points below the priority class.
0: (THREAD_PRIORITY_NORMAL) Normal priority for the priority class.
1: (THREAD_PRIORITY_ABOVE_NORMAL) Priority 1 point above the priority class.
2: (THREAD_PRIORITY_HIGHEST) Priority 2 points above the priority class.
15: (THREAD_PRIORITY_TIME_CRITICAL) Base-priority level of 15 for usual processes or 31 for REALTIME_PRIORITY_CLASS processes.

TEurekaThreadData.RealParameter

Real thread function's argument.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

RAW pointer argument for RealStartingAddress (appendix D, TEurekaThreadData.RealStartingAddress) thread function.

Remarks.

This property contains argument passed to thread function identified by RealStartingAddress (appendix D, TEurekaThreadData.RealStartingAddress) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.RealStartingAddress

Real thread function (pointer).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A pointer to thread function.

Remarks.

This property points to real thread function. That is a thread function for CreateThread/BeginThread/TThread.Execute.

A usual thread function is a function passed to CreateThread function. This value is stored in StartingAddress (appendix D, TEurekaThreadData.StartingAddress) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.RealStartingFunction

Real thread function (description).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A human-readable description of RealStartingAddress (appendix D, TEurekaThreadData.RealStartingAddress) property.

Remarks.

This value contains function name identified in RealStartingAddress (appendix D, TEurekaThreadData.RealStartingAddress) property. Function name is taken from debug information.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.StackTop

Top of thread's start.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A pointer to the beginning of the stack (top high address).

Remarks.

This value is used for call stack creation.

TEurekaThreadData.StartingAddress

Usual thread function (pointer).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A pointer to usual thread function.

Remarks.

This property points to usual thread function. That is a function passed directly to CreateThread - regardless of thread kind (appendix D, TEurekaThreadData.Kind).

A real thread function is a function passed to CreateThread/BeginThread/TThread.Execute functions. This value is stored in RealStartingAddress (appendix D, TEurekaThreadData.RealStartingAddress) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

Note. This property equals to RealStartingAddress property for Windows threads and differs for RTL threads.

TEurekaThreadData.StartingFunction

Usual thread function (description).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A human-readable description of StartingAddress (appendix D, TEurekaThreadData.StartingAddress) property.

Remarks.

This value contains function name identified in StartingAddress (appendix D, TEurekaThreadData.StartingAddress) property. Function name is taken from debug information.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadData.Thread

Thread object (class instance).

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

A thread class instance for the thread. Typically this is a TThread instance. This value is nil for Windows (appendix D, TEurekaThreadData.Kind) threads and for threads created with naked BeginThread function. This valus is not nil for TThread threads.

Remarks.

This property stores actual thread object. Use typecasting to cast this object to appropriate thread class.

This value is detected on thread's creation. It is not changed during thread's life-time. However, properties of the thread object may change.

TEurekaThreadData.ThreadClassName

Thread class name.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Value.

Name of thread class. Usually this value is TThread-descendant. ClassName.

Remarks.

This is class name of the class for the object in Thread (appendix D, TEurekaThreadData.Thread) property.

This value is detected on thread's creation. It is not changed during thread's life-time.

TEurekaThreadDataList

List of threads.

TEurekaThreadDataList = class(TCheckedInterfacedObject);

Remarks.

Represents thread list returned by ThreadDataEnum (appendix A) function.

Access to this list and to all items in the list does not require any locking/synchronization - because this list and all items are created upon ThreadDataEnum call.

This object is a "snapshot". It may not represent the actual state of threads in the application - because this state may be changed after taking the snapshot.

TEurekaThreadDataList.Count

Count of threads in the list.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Remarks.

This property indicate count of threads in current list. Use this property to enumerate all threads via Items (appendix D, TEurekaThreadDataList.Items) property. If you're interested in a particular thread - use ThreadData (appendix D, TEurekaThreadDataList.ThreadData) method.

TEurekaThreadDataList.Items

Provides access to individual threads in the list.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Parameters.

AIndex [in] — Index of a thread in the list. Index should be in 0.. Count (appendix D, TEurekaThreadDataList.Count)-1 range.

Remarks.

This is a default property for the TEurekaThreadDataList class.

This property can be used to enumerate all threads in the list. If you're interested in a particular thread - use ThreadData (appendix D, TEurekaThreadDataList.ThreadData) method.

TEurekaThreadDataList.ThreadData

Returns information about a particular thread.

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Parameters.

AThreadID [in] — TID (Thread ID) of a thread to get information.

Return value.

Information about the AThreadID thread. Do not destroy the returned object. This value could be nil if AThreadID does not identify a valid running thread.

Remarks.

Use this method to get information about a particular thread in the list.

There is no need to release the returned object.

There is no need to use locking - because the list and all items are created upon ThreadDataEnum call.

Any change for dynamic properties (such as Name, LastException, LastHTMLPage) will be ignored. Use ThreadData (appendix A) function to modify thread's dynamic properties.

EZip

Constructor TZipFile.Create

Create a TZipFile

public
constructor Create;

Destructor TZipFile.Destroy

public
destructor Destroy;
override;

Remarks.

Destroy will close an open zipfile before disposing of it

EZIPException

Exception type for all Zip errors.

EZIPException = class(Exception);

TZipFile

Class for creating and reading .ZIP files.

TZipFile = class(TObject);

TZipFile.Add

Add a file to the ZIP file

Add a memory file to the ZIP file

Add a memory file to the ZIP file. Allows programmer to specify the Local and Central Header data for more flexibility on what gets written. Minimal vailidation is done on the Header parameters; speficying bad options could result in a corrupted zip file.

public
procedure Add(
  const FileName: string;
  ArchiveFileName: string = '';
  Compression: TZipCompression = zcDeflate
); overload;
procedure Add(
  Data: TBytes;
  ArchiveFileName: string;
  Compression: TZipCompression = zcDeflate
); overload;
procedure Add(
  Data: Classes.TStream;
  ArchiveFileName: string;
  Compression: TZipCompression = zcDeflate
); overload;
procedure Add(
  Data: Classes.TStream;
  LocalHeader: TZipHeader;
  CentralHeader: PZipHeader = nil
); overload;

Parameters.

FileName

FileName to be added

ArchiveFileName

Path + Name of file in the arcive. If Ommitted, ExtractFileName(FileName) will be used.

Compression

Compression mode.

Data

Bytes to be added

ArchiveFileName

Path + Name of file in the arcive.

Compression

Compression mode.

Data

Stream of file to be added

ArchiveFileName

Path + Name of file in the arcive.

Compression

Compression mode.

Data

Stream of file to be added

LocalHeader

The local header data

CentralHeader

A Pointer to an optional central header. If no central Header is provided, the Local Header information is used.

TZipFile.Close

public
procedure Close;

Remarks.

Closing is required to write the ZipFile's Central Directory to disk. Closing a file that is open for writing writes additonal metadata that is required for reading the file.

TZipFile.Comment

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Remarks.

Comments can be a maximum of 65535 bytes long. If a longer comment is supplied, It is truncated before writing to the ZIP File.

TZipFile.Extract

Extract a single file

public
procedure Extract(
  const FileName: string;
  const Path: string = '';
  CreateSubdirs: Boolean = True
); overload;

Parameters.

FileName

File name in the archive

Path

Path to extract to disk

CreateSubdirs

The output should create sub directories specified in the ZIP file

Remarks.

FileName specifies a file in the ZIP file. All slashes in ZIP file names should be '/'. The overload that takes an Integer may be useful when a ZIP file has duplicate filenames.

TZipFile.ExtractAll

Extract All files

public
procedure ExtractAll(
  const Path: string = ''
);

Parameters.

Path

Path to extract to.

TZipFile.ExtractZipFile

Extract a ZipFile

public
class function ExtractZipFile(
  const ZipFileName, Path: String;
  const APassword: String = ''
): String; static;

Parameters.

ZipFileName

File name of the ZIP file

Path

Path to extract to disk

TZipFile.FileComment

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Remarks.

File Comments can be changed for files opened in write mode at any point. The comment is written when the Central Directory is written to disk. Comments can be a maximum of 65535 bytes long. If a longer comment is supplied, It is truncated before writing to the ZIP File.

TZipFile.FileCount

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

Total files in ZIP File

TZipFile.FileInfo

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

TZipHeader of a File in the ZipFile

TZipFile.FileInfos

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

An array of the TZipHeader of the files in the ZIP file

TZipFile.FileName

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

FileName of a File in the ZipFile

TZipFile.FileNames

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

An array of FileNames in the ZIP file

TZipFile.IndexOf

Translate from FileName to index in ZIP Central Header

public
function IndexOf(
  const FileName: string
): Integer;

Parameters.

FileName

Path + Name of file in the arcive.

Return value.

The index of the file in the archive, or -1 on failure.

Remarks.

A ZIP file may have dupicate entries with the same name. This function will return the index of the first.

TZipFile.IsValid

Verifies .ZIP file

public
class function IsValid(
  const ZipFileName: String
): Boolean; static;

Parameters.

ZipFileName

Path to Zip File

Return value.

Is the .ZIP file valid

TZipFile.Mode

Declaration unavailable: behavior or values are described, but no public property/event declaration is specified here. Its type, accessors and writeability must not be inferred from the name.

Return value.

The mode the TZipFile is opened to

TZipFile.Open

Opens a ZIP file for reading or writing.

public
procedure Open(
  const ZipFileName: string;
  OpenMode: TZipMode
); overload;

Parameters.

ZipFileName

Path to ZipFile

OpenMode

File Mode to open file. zmWrite Creates a new ZIP file for writing. zmReadWrite Opens the file for reading and allows adding additional new files. zmRead Opens the file for reading.

TZipFile.Read

Read a file from arcive to an array of Bytes

Get a stream to read a file from disk

public
procedure Read(
  const FileName: string;
  out Bytes: TBytes
); overload;
procedure Read(
  const FileName: string;
  out Stream: Classes.TStream;
  out LocalHeader: TZipHeader
); overload;

Parameters.

FileName

ZIP file FileName

Bytes

Output bytes

FileName

ZIP file FileName

Stream

Output Stream

LocalHeader

Local File header

Remarks.

The overload that takes an Integer may be useful when a ZIP file has duplicate filenames.

The Stream returned by this function is a decomression stream wrapper around the interal Stream reading the zip file. You must Free this stream before using other TZipFile methods that change the contents of the ZipFile, such as Read or Add. The overload that takes an Integer may be useful when a ZIP file has duplicate filenames.

TZipFile.ZipDirectoryContents

Zip the contents of a directory

public
class procedure ZipDirectoryContents(
  const ZipFileName, Path: String;
  Compression: TZipCompression = zcDeflate;
  const APassword: String = ''
); static;

Parameters.

ZipFileName

File name of the ZIP file

Path

Path of directory to zip

Compression

Compression mode.

TEurekaModuleOptions option-property reference

These property names correspond to the configuration options described below. No public Pascal declarations, accessor names or complete default constructor state are specified here. A value description is not a substitute for a declaration: do not infer a property's type or writeability from this table. Only explicitly documented values and defaults are listed. This list is not a claim that every setting shown by every EurekaLog build has a public property.

Use EModules.CurrentEurekaLogOptions only when EurekaLog is active; it can fail when inactive (appendix A). Event-local Options lets you adjust the report being processed without assuming the same scope as global options. Operational configuration belongs in chapters 24-25 and 3.

Sending security: an embedded password or token is recoverable even when encrypted in the executable. Use a dedicated least-privilege reporting identity or a server-side facade; never ship a normal user's or administrator's credentials. Some tracker setup descriptions require privileged discovery or configuration. That requirement does not justify embedding the privilege in a deployed application. HTTPS and its port must be configured deliberately. A passing small test does not establish that the server accepts the full report and attachments.

Availability: WER-related settings below describe named configuration fields only. No public behavioral or callable contract is specified here for the WER dialog. Do not infer a functioning WER path from those names.

Examples: a host name given in the tables below as an example is a placeholder for your own server, written as a literal value because that is what the option holds. The names under example.com are reserved for documentation (RFC 2606) and serve nothing: replace them with the real host of your tracker, mail relay or upload endpoint.

TEurekaModuleOptions — Advanced page

Property names Documented value and constraints

ThreadStackGuarantee "Stack Reserve for handling overflows" option sets the minimum size of the stack that will be available during any stack overflow exceptions. This is useful for handling stack overflow exceptions; the application can safely use the specified number of bytes during exception handling. If the specified size is less than the current/previous reserve size - it will be ignored. Therefore, you cannot use decrease the stack reserve. This value cannot be larger than the reserved stack size (1 Mb by default). Stack reserve will be applied automatically for all threads created while EurekaLog is active. Alternatively, you may call EnsureThreadStack (appendix A) function in any thread to apply the option to the calling thread. Usually it is not necessary to change/increase this option, because EurekaLog will automatically process any stack overflow exception in a standalone background service thread.

Property names	Documented value and constraints
`ThreadStackGuarantee`	"Stack Reserve for handling overflows" option sets the minimum size of the stack that will be available during any stack overflow exceptions. This is useful for handling stack overflow exceptions; the application can safely use the specified number of bytes during exception handling. If the specified size is less than the current/previous reserve size - it will be ignored. Therefore, you cannot use decrease the stack reserve. This value cannot be larger than the reserved stack size (1 Mb by default). Stack reserve will be applied automatically for all threads created while EurekaLog is active. Alternatively, you may call EnsureThreadStack (appendix A) function in any thread to apply the option to the calling thread. Usually it is not necessary to change/increase this option, because EurekaLog will automatically process any stack overflow exception in a standalone background service thread.

TEurekaModuleOptions — Bug report page

Property names	Documented value and constraints
`SaveLogFile`	"Save bug report to file" option enables saving full exception information report into a file. This file is plain-text report file, which can be viewed in any text editor or special viewer application: EurekaLog Viewer (chapter 4). Bug report contains information specified on Bug report content (chapter 4) page. Single file can contains multiple problem reports.
`OutputPath`	"Bug report's location" option specifies path on file system, where you want to save bug report. Default is a project's subfolder in "%APPDATA%\Neos Eureka S.r.l\Bug reports" (report filenames and locations (chapter 25)). Empty string means default path (i.e. the same folder - "%APPDATA%\Neos Eureka S.r.l\Bug reports"). You can use environment variables (chapter 25) to specify dynamic-changed paths. This option can specify folder only (ends with path separator - ''). In this case: default file name ("your-project.el" - for example: "Project1.el") will be used. Alternatively, you can specify both path + file name. In this case: specified custom file name will be used. See chapter 25 for filename configuration. If you want to save bug report to the same folder as executable module - use "." folder. You can also use any other relative path, like this for example: ".\Reports". Do not save bug report to .exe's folder, if you install your application to Program Files. Use exe's folder only for mobile applications (for example: runnable from flash sticks).
`ErrorsNumberToSave`	"Max. reports in one file" option allows you to limit capacity of a single file. It specifies how many bug reports can be hold in 1 file. Once limit is exceeded, oldest report in file will be deleted and new report will be saved as last report. Value of 0 means unlimited bug report file. Typical values can be 0, 1, 32, 256, 9999, etc. Setting this option to 1 is almost equivalent of (non-existed) "delete log file before exception" option. Note: if you set this option to any value other than 1, then you should review if you want to enable the "Send entire bug report file with multiple reports" option (chapter 3) too. Important Note: if you set this value to 0 (or a very large number) - be sure that you have some way to clean up your bug report file from time to time. Otherwise it will grow until all free hard disk space is exhausted.

TEurekaModuleOptions — Console

Property names	Documented value and constraints
`ExceptionDialogType`	"Detailed mode" option includes a compact call stack to the error message. For example:
`ExceptionDialogType`	"Bug report dump" option replaces error message and a call stack with a copy of the bug report. For example: If you enable this mode - it may be a good idea to disable some parts of bug report (especially modules and processes lists), because large bug report will not fit into console. This may not matter, if you use output redirection.

TEurekaModuleOptions — EurekaLog

Property names	Documented value and constraints
`ExceptionDialogType`	You can control whenever dialog is initially showed in standard or detailed mode by switching "Default: detailed mode" option.
`ErrorsNumberToShowTerminateBtn`, `TerminateBtnOperation`	"Do nothing" / "Show 'Restart' checkbox" / "Show 'Terminate' checkbox" after N errors options controls the visibility of "restart" and "terminate" checkboxes: "Show 'Terminate' checkbox" options is selected and error count is more than the specified count. The "Checked" option controls if this checkbox is initially checked or unchecked. If "Checked" option is checked, then when EurekaLog dialog appears with restart/terminate button visible - this button will be default. And the opposite: if the "Checked" option is not checked, then a default button will be OK button, when dialog appears. Of course, this option have no effect, if button is not visible (for example, if you select "Do nothing" option). A "after N errors" part is controls, when to show restart/terminate checkbox. Again, this part is ignored, if you select "Do nothing" option. Value of 0 means that restart/terminate button will be visible always. Value of 1 means that button will be displayed only in second error dialog. Value of 2 means that you got two error dialog without button and 3rd dialog will have it. And so on. At run-time: when user clicks restart/terminate button, then your application will be restarted or terminated after closing error dialog and saving and sending bug report (if enabled). If user clicks OK button - then your application will continue to run. - If restart/terminate is enforced (for example, when it is dictated by restart/recovery options or when emergency safe mode is activated) - then OK button will not be visible. - EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option (chapter 25).
`AutoCloseDialogSecs`	"Close every exception dialog after M seconds" option allows you to automatically close exception dialogs after timeout of inactivity. Value of 0 means disabling of such feature - i.e. each dialog may be closed only manually by user (via clicking on dialog's buttons). Any other value (> 0) means that dialog will be closed after that amount of seconds, passed since its popup. For example, if you specify 180 seconds - then dialog will be closed exactly after 3 minutes, if user didn't closed it before. This option is useful to auto-close error dialogs in possible non-interactive scenarios. Note, that it may be preferable to select other dialog type (non-GUI) in such cases. Note: this option specifies the delay of user's inactivity. If user moves mouse, presses buttons or generates any other input in dialog - auto-close timer will reset. Therefore, setting this option to, say, 5 seconds does not mean that dialog will be closed after 5 seconds. It may stay for, say, 1 minute - but only if user is working with it. Dialog will be closed after 5 seconds if user is away (not moving mouse, etc.).
`ForegroundTab`	"Foreground tab" specifies the default active tab in detailed view when dialog is showed. For example:
`SupportURL`	"Support URL" option allows you to specify an URL, which will be shown in error dialog as hyper-link. Empty value means "do not show hyper-link". For example: At run-time: user can click on that hyper-link and EurekaLog will open a default browser with specified URL. Dialog itself will not be closed. Note: support URL may include any variable (chapter 25). For example, you may specify the following URL: `https://bugs.example.com/view.php?find=%_BugID%`. When user click on support URL, EurekaLog will open the following URL in user's default browser: `https://bugs.example.com/view.php?find=CFAC0000` (where "CFAC0000" - is just an example of Bug ID (chapter 8); it will be different in your case). This allows you to dynamically customize support page.

TEurekaModuleOptions — MessageBox

Property names	Documented value and constraints
`ExceptionDialogType`	"Detailed mode" option switches between standard mode and detailed mode. Standard mode shows error message only. Detailed mode shows error message and compact call stack. For example:

TEurekaModuleOptions — MS Classic

Property names Documented value and constraints

ErrorsNumberToShowTerminateBtn, TerminateBtnOperation "Do nothing" / "Show 'Restart' checkbox" / "Show 'Terminate' checkbox" after N errors option controls the visibility of "restart" and "terminate" checkboxes: "Show 'Terminate' checkbox" options is selected and error count is more than the specified count. The "Checked" option controls if this checkbox is initially checked or unchecked. If "Checked" option is checked, then when MS Classic dialog appears with restart/terminate checkbox visible - this checkbox will be checked. And the opposite: if the "Checked" option is not checked, then restart/terminate checkbox will be unchecked, when dialog appears. Of course, this option have no effect, if checkbox is not visible (for example, if you select "Do nothing" option). A "after N errors" part is controls, when to show restart/terminate checkbox. Again, this part is ignored, if you select "Do nothing" option. Value of 0 means that restart/terminate checkbox will be visible always. Value of 1 means that checkbox will be displayed only in second error dialog. Value of 2 means that you got two error dialog without checkbox and 3rd dialog will have it. And so on. At run-time: when user checks restart/terminate checkbox, then your application will be restarted or terminated after closing error dialog and saving and sending bug report (if enabled). If user unchecks the checkbox - then your application will continue to run. Note: - If restart/terminate is enforced (for example, when it is dictated by restart/recovery options or when emergency safe mode is activated) - then restart/terminate checkbox will be visible and disabled. - EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option (chapter 25).

AutoCloseDialogSecs "Close every exception dialog after M seconds" option allows you to automatically close exception dialogs after timeout of inactivity. Value of 0 means disabling of such feature - i.e. each dialog may be closed only manually by user (via clicking on dialog's buttons). Any other value (> 0) means that dialog will be closed after that amount of seconds, passed since its popup. For example, if you specify 180 seconds - then dialog will be closed exactly after 3 minutes, if user didn't closed it before. This option is useful to auto-close error dialogs in possible non-interactive scenarios. Note, that it may be preferable to select other dialog type (non-GUI) in such cases. Note: this option specifies the delay of user's inactivity. If user moves mouse, presses buttons or generates any other input in dialog - auto-close timer will reset. Therefore, setting this option to, say, 5 seconds does not mean that dialog will be closed after 5 seconds. It may stay for, say, 1 minute - but only if user is working with it. Dialog will be closed after 5 seconds if user is away (not moving mouse, etc.).

Property names	Documented value and constraints
`ErrorsNumberToShowTerminateBtn`, `TerminateBtnOperation`	"Do nothing" / "Show 'Restart' checkbox" / "Show 'Terminate' checkbox" after N errors option controls the visibility of "restart" and "terminate" checkboxes: "Show 'Terminate' checkbox" options is selected and error count is more than the specified count. The "Checked" option controls if this checkbox is initially checked or unchecked. If "Checked" option is checked, then when MS Classic dialog appears with restart/terminate checkbox visible - this checkbox will be checked. And the opposite: if the "Checked" option is not checked, then restart/terminate checkbox will be unchecked, when dialog appears. Of course, this option have no effect, if checkbox is not visible (for example, if you select "Do nothing" option). A "after N errors" part is controls, when to show restart/terminate checkbox. Again, this part is ignored, if you select "Do nothing" option. Value of 0 means that restart/terminate checkbox will be visible always. Value of 1 means that checkbox will be displayed only in second error dialog. Value of 2 means that you got two error dialog without checkbox and 3rd dialog will have it. And so on. At run-time: when user checks restart/terminate checkbox, then your application will be restarted or terminated after closing error dialog and saving and sending bug report (if enabled). If user unchecks the checkbox - then your application will continue to run. Note: - If restart/terminate is enforced (for example, when it is dictated by restart/recovery options or when emergency safe mode is activated) - then restart/terminate checkbox will be visible and disabled. - EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option (chapter 25).
`AutoCloseDialogSecs`	"Close every exception dialog after M seconds" option allows you to automatically close exception dialogs after timeout of inactivity. Value of 0 means disabling of such feature - i.e. each dialog may be closed only manually by user (via clicking on dialog's buttons). Any other value (> 0) means that dialog will be closed after that amount of seconds, passed since its popup. For example, if you specify 180 seconds - then dialog will be closed exactly after 3 minutes, if user didn't closed it before. This option is useful to auto-close error dialogs in possible non-interactive scenarios. Note, that it may be preferable to select other dialog type (non-GUI) in such cases. Note: this option specifies the delay of user's inactivity. If user moves mouse, presses buttons or generates any other input in dialog - auto-close timer will reset. Therefore, setting this option to, say, 5 seconds does not mean that dialog will be closed after 5 seconds. It may stay for, say, 1 minute - but only if user is working with it. Dialog will be closed after 5 seconds if user is away (not moving mouse, etc.).

TEurekaModuleOptions — System log reporting

Property names	Documented value and constraints
`EventLogComputer`	"Computer name" option identifies a computer to log error message. This is the first parameter to be passed to OpenEventLog. Leave this option empty to use the current machine.
`EventLogName`	"Event source name" option identifies event source to log error message. This is the second parameter to be passed to OpenEventLog. This is the name which you've used during your application's registration (chapter 23) in system event log. This parameter is required.
`EventLogCategory`	"Category ID" option is optional parameter which specifies a category for error message. Leave it empty if you don't use categories. Category ID is established during application's registration (chapter 23).
`EventLogEventID`	"Message ID" option identifies a message to use when logging error message. This parameter is required. Message ID is established during application's registration (chapter 23). - Register your application in system event log (chapter 23). - Specify "message ID" in system log reporting dialog (chapter 23). Tip: Message ID usually have form of $C002XXXX. Where XXXX is ID of your event (such as 1, 2, etc.) in hexadecimal form.

TEurekaModuleOptions — WEB

Property names Documented value and constraints

WebErrorCode "HTTP Error Code" option specifies value of HTTP Status Code to be returned to client's web browser when exception is occurred. - 200 status code means success/OK, and it is a usual status code to be returned to client when web application produces content page without any error. Use this status code to produce error message as normal web pages. - 500 error code means internal server error, and it is a typical error code to be returned when something goes wrong with web application. Use this or any other error code to indicate failure to client's web browser. Important note: some web application implementations (server or browser) may ignore actual page content for status codes like 500 error code. This means that customized HTML page (see "HTML layout" option below) will be ignored. Use 200 status code for such cases. Note: not all web application supports returning custom status code for error page. Support for this feature depends on used framework, its version and its configuration.

HTMLLayout "HTML layout" option specifies an HTML page template to be send to client in case of error during its request's processing. E.g. this is an error HTML page. You can put any text here, the resulting page will be exactly the same as you specified here. You can customize error HTML page to match your web-site.

Property names	Documented value and constraints
`WebErrorCode`	"HTTP Error Code" option specifies value of HTTP Status Code to be returned to client's web browser when exception is occurred. - 200 status code means success/OK, and it is a usual status code to be returned to client when web application produces content page without any error. Use this status code to produce error message as normal web pages. - 500 error code means internal server error, and it is a typical error code to be returned when something goes wrong with web application. Use this or any other error code to indicate failure to client's web browser. Important note: some web application implementations (server or browser) may ignore actual page content for status codes like 500 error code. This means that customized HTML page (see "HTML layout" option below) will be ignored. Use 200 status code for such cases. Note: not all web application supports returning custom status code for error page. Support for this feature depends on used framework, its version and its configuration.
`HTMLLayout`	"HTML layout" option specifies an HTML page template to be send to client in case of error during its request's processing. E.g. this is an error HTML page. You can put any text here, the resulting page will be exactly the same as you specified here. You can customize error HTML page to match your web-site.

TEurekaModuleOptions — Windows Error Reporting

Property names	Documented value and constraints
`WERPassThroughUnhandled`	"Pass through unhandled exceptions" option enables special mode for real unhandled exceptions (chapter 8). Once checked, this option will redirect such exceptions directly to the system, ignoring any application's processing code. All other exceptions will be processed as usual. In other words, if you check this option - then all your customizations will be ignored (for real unhandled exceptions only). This option is useful to get exact state of the application by using minidumps (chapter 4 (availability limitations)), since all processing are ignored. So you can get the closest possible image of the problem.
`WERPassThroughUnexpected`	"Pass through critical exceptions" option do the same thing as "Pass through unhandled exceptions", but do this for "critical" exceptions. Critical exception are the exceptions which you should not handle at all. This includes exceptions such as access violations. All other exceptions (like EStreamError) will behave as usual. Warning: you won't be able to catch critical exceptions with try/except blocks. Bug report will be send and application will be terminated immediately upon critical exception raising. All other exceptions will behave normally. This option has no effect if "Pass through unhandled exceptions" option is not checked.
`WERCustomizeReport`	"Personalize report" option will report basic information and description of the application to the system error processing. If not checked - system will extract information on its own. Usually the results of both methods are very close.
`WERSubmitHonorRecovery`	"Honor recovery" option follows any recovery registration for the application. This option is related to Restart & Recovery API in Windows Vista+. If this option is unchecked - WER will not perform any registered recovery activities.
`WERSubmitHonorRestart`	"Honor restart" option follows any restart registration for the application. This option is related to Restart & Recovery API in Windows Vista+. If this option is unchecked - WER will not perform any registered restart activities.
`WERSubmitNoArchive`	Unchecking the "Allow archive report" option will disable report's archiving.
`WERSubmitNoQueue`	"Allow queue report" option allows to queue report for later send, if sending is not possible now. If this option is unchecked - report will never be queued. If there is adequate user consent the report is sent to Microsoft immediately; otherwise, the report is discarded. The report is discarded for any action that would require the report to be queued. For example, if the computer is offline when you submit the report, the report is discarded. Also, if there is insufficient consent (for example, consent was required for the data portion of the report), the report is discarded.
`WERSubmitQueue`	"Force queue" option adds the report to the WER queue without notifying the user. The report is queued only - reporting (sending the report to Microsoft) occurs later based on the user's consent level.
`WERSubmitOutOfProcess`	"Send out of process" option spawns another process to submit the report. The calling thread is blocked until the function returns.
`WERSubmitAddRegisteredData`	"Add registered data" option adds the data registered by WerSetFlags, WerRegisterFile, and WerRegisterMemoryBlock to the report.
`WERSubmitNoCloseUI`	"Show close UI" option displays dialog this "Close application" button: If this option is unchecked - there will be no such dialog. Other dialogs (like sending report and searching for the solution) will be present.
`WERSubmitShowDebug`	"Show debug" option shows a "Debug" button to launch and attach a default debugger.
`WERSubmitStartMinimized`	"Start minimized" option runs initial UI as minimized and flashing.

TEurekaModuleOptions — Dialogs page

Property names	Documented value and constraints
`ExceptionDialogType`	Select appropriate dialog type for your application from "Dialog type" combo-box and specify all other options for the specific dialog type:

TEurekaModuleOptions — Exceptions filters page

Property names Documented value and constraints

ActivateFilters "Activate Exceptions Filters" option enables or disables exception filters globally. Exceptions filter below will have no effect when this option is disabled.

ExceptionsFilters "Exception Filters" option defines one or more exception filter. Usually exceptions are identified by exception's class name. You can also identify exception by source location. And you can identify exception by its type (handled or unhandled). Once exception is identified - you can change handler for it (none, RTL or EurekaLog), dialog class (to any of existing dialog classes), override error message or set action (restart or terminate). Exception filters are applied before processing exception. Filters are applied in order from top to bottom. First matched filter is applied. - % in exception message means that exception's message must contain the specified value. - Click on "Add" button to add new filter (chapter 25). - You can double-click on existing filter to edit (modify) selected filter (chapter 25). - You can use "Move up"/"Move down" buttons, Ctrl + Up/Ctrl + Down or simple mouse dragging to re-order filters. Note: sometimes it's more easier to use custom attributes (chapter 24) instead of exception filters. Important note: ensure that features specified in exception filters will be available at run-time. For example, if your application uses MS Classic-styled exception dialog by default and you want to switch to EurekaLog-styled dialog for some exceptions by using exception filters - then be sure to include code for EurekaLog dialog into your application (chapter 25).

Property names	Documented value and constraints
`ActivateFilters`	"Activate Exceptions Filters" option enables or disables exception filters globally. Exceptions filter below will have no effect when this option is disabled.
`ExceptionsFilters`	"Exception Filters" option defines one or more exception filter. Usually exceptions are identified by exception's class name. You can also identify exception by source location. And you can identify exception by its type (handled or unhandled). Once exception is identified - you can change handler for it (none, RTL or EurekaLog), dialog class (to any of existing dialog classes), override error message or set action (restart or terminate). Exception filters are applied before processing exception. Filters are applied in order from top to bottom. First matched filter is applied. - % in exception message means that exception's message must contain the specified value. - Click on "Add" button to add new filter (chapter 25). - You can double-click on existing filter to edit (modify) selected filter (chapter 25). - You can use "Move up"/"Move down" buttons, Ctrl + Up/Ctrl + Down or simple mouse dragging to re-order filters. Note: sometimes it's more easier to use custom attributes (chapter 24) instead of exception filters. Important note: ensure that features specified in exception filters will be available at run-time. For example, if your application uses MS Classic-styled exception dialog by default and you want to switch to EurekaLog-styled dialog for some exceptions by using exception filters - then be sure to include code for EurekaLog dialog into your application (chapter 25).

TEurekaModuleOptions — Hang detection page

Property names Documented value and constraints

FreezeDisableUnderDebugger "Disable under debugger" option will disable hang detection feature if you run your application under debugger. The hang detection will be enabled when application run outside of IDE/debugger. Note: this option has no effect if "Activate UI hang detection with timeout" option is not checked. Important note: it is recommended to enable this option when debugging your application. Time spend in the debugger will be accounted for non-responding time of your application. Thus, a hang report may be triggered while you are debugging your application. Use this option to avoid such false-positive reports.

Property names	Documented value and constraints
`FreezeDisableUnderDebugger`	"Disable under debugger" option will disable hang detection feature if you run your application under debugger. The hang detection will be enabled when application run outside of IDE/debugger. Note: this option has no effect if "Activate UI hang detection with timeout" option is not checked. Important note: it is recommended to enable this option when debugging your application. Time spend in the debugger will be accounted for non-responding time of your application. Thus, a hang report may be triggered while you are debugging your application. Use this option to avoid such false-positive reports.

TEurekaModuleOptions — Multi-threading page

Property names Documented value and constraints

ConsecutiveProcessing "Consecutive processing" option acquires a global lock during exception processing. While not recommended, but you can enable this option for visual/GUI multi-threaded applications which show exception dialogs from background threads. Enabling this option means that simultaneous exceptions will be processed (shown) one after another in a consecutive manner. E.g. only one dialog will be visible at the same time. It also mean that exception processing performance will be lower, because several threads will be unable to process multiple exceptions at the same time. For this reason - we recommend to write your code in a such way that only main thread will show exception dialogs. Thus, you will not need to enable this option. You can achieve this by using TThread(Ex) and handling .FatalException property in the main thread. Important Note: enabling this option does not mean that you can avoid adding proper synchronization to your EurekaLog's event handlers if you are accessing global data, because exception processing will be performed by active thread. E.g. exception in a background thread will be processed by the same background thread, and event handlers will be called by the same background thread. On other hand, introducing additional locks may lead to a deadlock in rare cases. Therefore, we recommend to avoid using global data in your EurekaLog's event handlers if you enable this option. Important Note: this option affects exception processing only for exception from multiple background threads. It does nothing to alter behavior of multiple exceptions within a single thread. For example, if you have a code like this:

Property names	Documented value and constraints
`ConsecutiveProcessing`	"Consecutive processing" option acquires a global lock during exception processing. While not recommended, but you can enable this option for visual/GUI multi-threaded applications which show exception dialogs from background threads. Enabling this option means that simultaneous exceptions will be processed (shown) one after another in a consecutive manner. E.g. only one dialog will be visible at the same time. It also mean that exception processing performance will be lower, because several threads will be unable to process multiple exceptions at the same time. For this reason - we recommend to write your code in a such way that only main thread will show exception dialogs. Thus, you will not need to enable this option. You can achieve this by using TThread(Ex) and handling .FatalException property in the main thread. Important Note: enabling this option does not mean that you can avoid adding proper synchronization to your EurekaLog's event handlers if you are accessing global data, because exception processing will be performed by active thread. E.g. exception in a background thread will be processed by the same background thread, and event handlers will be called by the same background thread. On other hand, introducing additional locks may lead to a deadlock in rare cases. Therefore, we recommend to avoid using global data in your EurekaLog's event handlers if you enable this option. Important Note: this option affects exception processing only for exception from multiple background threads. It does nothing to alter behavior of multiple exceptions within a single thread. For example, if you have a code like this:

TEurekaModuleOptions — Exceptions page

Property names	Documented value and constraints
`NestedExceptionStack`	"Log first (bottom/nested) exception" option force EurekaLog to use original exceptions (nested root) for logging. This includes class, message, call stack, BugID and other exception-related properties to be stored in log file, shown in "detailed" dialogs and/or sent over network. This option doesn't affect any other visual appearance. If there is no nested exception - this option will have no effect, the behavior will be the same as if "Log last (top) exception" would be selected. This option is recommended option for typical application.
`NestedExceptionStack`	"Log last (top/chained) exception" option force EurekaLog to use chained exceptions for logging. This includes class, message, call stack, BugID and other exception-related properties to be stored in log file, shown in "detailed" dialogs and/or sent over network. This option doesn't affect any other visual appearance. Use this option for backward-compatible behavior.
`NestedExceptionMessage`	"Show first (bottom/nested) exception" option force EurekaLog to use original exceptions (nested root) for visual display. This includes error messages, dialogs and other visual interactions with user. This option doesn't affect logging. If there is no nested exception - this option will have no effect, the behavior will be the same as if "Show last (top) exception" would be selected.
`NestedExceptionMessage`	"Show last (top/chained) exception" option force EurekaLog to use chained exceptions for visual display. This includes error messages, dialogs and other visual interactions with user. This option doesn't affect logging. This is recommended option for most project types.
`NestedExceptionMessage`	"Show all exceptions" option force EurekaLog to show messages from all currently active exceptions (each message on new line). This includes error messages, dialogs and other visual interactions with user. This option doesn't affect logging. This is default behavior of Delphi and C++ Builder applications starting with Delphi 2009, but it's generally not recommended (unless you want extra-detailed error display).
`CustomExceptionMessage`	"Custom" option allows you to override any exception message with custom string. This option is used for error messages, dialogs and other visual interactions with user. This option doesn't affect logging. Specifying a message will override any exception message with the specified string. Use this option to hide implementation details from end-user. Message overriding can also be done by using exception filters (chapter 24) or custom attributes (chapter 24).
`UseExceptionComments`	"Use exception's custom message if available" option allow you to override exception message with custom string individually for each exception. This option is used for error messages, dialogs and other visual interactions with user. This option doesn't affect logging. It can be combined with any of the previous options (items 3-6). Each exception has associated .AdditionalInfo field. You can store any information in that field. It's like Tag field, except it has String type. - If this option is checked and there is any value in that field - it will be used instead of actual exception message. - If this option is unchecked or field is empty - Message property will be used. You can use this feature to override original message with custom message, but still preserve original information. This override is used only for visual display. Log files are unaffected. This feature allows you to use per-exception override (see also "Override Exception Message" option (chapter 25)). If you want to override all messages - just use "Custom" option above. Note: some error dialogs like WER (the WER availability caveat in appendix D) and system logging (chapter 23) do not display error message to user (instead, they log exception details). Thus, such dialog are unaffected by the options above (items 3-7).
`SecondaryExceptions`	"Do nothing special" option will tell EurekaLog that it should act as RTL. In other words, no special actions will be taken. This means that any secondary exception will trigger EurekaLog (again) and will be processed as any other exception. Use this option if you want most details (e.g. reports about each and every exception). Warning: make sure to set up auto-restart (chapter 25) when using this option, because your application may enter endless cycle of showing secondary exceptions.
`SecondaryExceptions`	"Ignore like EAbort" option will tell EurekaLog to completely ignore all exceptions while displaying exception dialog. Warning: this option will not prevent secondary exceptions from being thrown. Secondary exceptions will be raised, processed, but will be silently ignored (e.g. no bug report, no dialog, no sending). This option is recommended, because it allows your application (main window) to remain responsive, while blocks exception dialogs from secondary exceptions.
`SecondaryExceptions`	"Block thread" option will tell EurekaLog to handle each exception in a service background thread. Running exception dialog in a background thread ensures that any secondary exceptions from exception's thread will not affect exception's dialog. Original exception's thread will be blocked until background thread finishes.

TEurekaModuleOptions — Restart&Recovery page

Property names Documented value and constraints

AutoCrashMinutes, AutoCrashNumber, AutoCrashOperation "None/Restart/Terminate" option specifies action to trigger when more than specified number of errors occurs in less than specified amount of time interval. None option will disable this feature. Restart option will automatically restart application. Terminate option will automatically close application. Use this option to automatically restart/terminate application in case of "exception spam" - i.e. when large numbers of exception occurs in a short amount of time. For example, "terminate after 20 errors in 1 minute" option means that if there is about 60/20 = 3 seconds (on average) between exceptions (dialogs) - application will be closed after around 1 minute. - This option is independent from error dialogs. If you want restart options to be controlled by end-user - then setup appropriate options for dialogs (chapter 25), do not enable this feature. - EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option.

LogAppExits "Log application's exits" option will create a log file with call stack for unexpected application's exits. Use this option to diagnose unexpected termination of your application. Important Note: Created process exit log file is not subject to usual exception processing. E.g. it will not show any dialog, will not be send to developers, etc. This is because log may be created for expected application's exits. If you want to receive such log from a remote PC - you can ask user to send it manually, send it on next startup (chapter 3), or attach it to your next exception report. - This option requires "Low level hooks" option (chapter 25) to be enabled.

Property names	Documented value and constraints
`AutoCrashMinutes`, `AutoCrashNumber`, `AutoCrashOperation`	"None/Restart/Terminate" option specifies action to trigger when more than specified number of errors occurs in less than specified amount of time interval. None option will disable this feature. Restart option will automatically restart application. Terminate option will automatically close application. Use this option to automatically restart/terminate application in case of "exception spam" - i.e. when large numbers of exception occurs in a short amount of time. For example, "terminate after 20 errors in 1 minute" option means that if there is about 60/20 = 3 seconds (on average) between exceptions (dialogs) - application will be closed after around 1 minute. - This option is independent from error dialogs. If you want restart options to be controlled by end-user - then setup appropriate options for dialogs (chapter 25), do not enable this feature. - EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option.
`LogAppExits`	"Log application's exits" option will create a log file with call stack for unexpected application's exits. Use this option to diagnose unexpected termination of your application. Important Note: Created process exit log file is not subject to usual exception processing. E.g. it will not show any dialog, will not be send to developers, etc. This is because log may be created for expected application's exits. If you want to receive such log from a remote PC - you can ask user to send it manually, send it on next startup (chapter 3), or attach it to your next exception report. - This option requires "Low level hooks" option (chapter 25) to be enabled.

TEurekaModuleOptions — BugZilla

Property names	Documented value and constraints
`SendBugZillaURL`	"URL" option specifies target URL for your BugZilla installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/bugzilla/` Warning: be sure to setup adequate maximum upload file limits in your web-server/BugZilla configuration. Otherwise sending may fail on large bug reports.
`SendBugZillaPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendBugZillaSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendBugZillaLogin`, `SendBugZillaPassword`	"Login" and "Password" options specify your account on BugZilla server. This account will be used to submit bug reports. You can use API token instead of password - leave login field blank in this case. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use BugZilla admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: BugZilla setup (chapter 3), Security Considerations (chapter 3). Note: it is a good idea to disable e-mail notifications for this account.
`SendBugZillaBasicAuthLogin`, `SendBugZillaBasicAuthPassword`	"BasicAuth" options specify account details for Basic-Auth type authentication. Usually these fields are blank. Fill them, if you use Basic-Auth on your web server.
`SendBugZillaProxyHost`, `SendBugZillaProxyLogin`, `SendBugZillaProxyPassword`, `SendBugZillaProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendBugZillaProject`	"Project" options specifies project name to store bug reports. It's mandatory.
`SendBugZillaOwner`	"Assign to" option specifies owner account name. If this option is empty, all submitted bug reports will be assigned to default account (configured in BugZilla options). If you enter here any account name - all submitted bug reports will be assigned to this account. Note: this option is ignored, if submitted bug report already exists (submitting a known issue).
`SendBugZillaComponent`	"Component" option specifies category for submitted reports. It can be optional or mandatory - it depends on your BugZilla version and project configuration.
`SendBugZillaCountFieldName`	""Count" field name" option specifies name of custom field, which EurekaLog will use for bug report counting. By default, BugZilla doesn't have any "occurrences" or "count" fields, so you can't know how many times bug has occurred. To workaround this problem, you can create a custom field in BugZilla configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs. Note: we highly recommend to create and use this field.
`SendBugZillaEMailFieldName`	""E-mail" field name" option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, BugZilla doesn't have such field. You can either create a custom field in BugZilla configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach).
`SendBugZillaBugIDFieldName`	""BugID" field name" option specifies name of custom field, which EurekaLog will use to store BugID (chapter 8). By default, BugZilla doesn't have such field. You can create a custom field in BugZilla configuration, which you will use for this purpose. It is purely optional, as EurekaLog will use internal alias for merging.
`SendBugZillaInProgressStatuses`	"In progress statuses" option specifies which statuses indicate that issue is IN PROGRESS. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendBugZillaUseHardware`	"Use/fill "Hardware" field" option instructs EurekaLog to use "Hardware" field in BugZilla. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog.
`SendBugZillaUseOS`	"Use/fill "OS" field" option instructs EurekaLog to use "OS" field in BugZilla. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog.
`SendBugZillaUseVersion`	"Use/fill "Version" field" option instructs EurekaLog to use "Version" field in BugZilla. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog. - You must enter valid versions into BugZilla's configuration. You also need to store version information in your executables to fill this field. - A project version will be used during sending. The version is extracted from version information of your project's executable. - Exception's module version is not used for sending (unless exception's module matches project's module).
`SendBugZillaMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendBugZillaUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports. - you can also stop collecting files by changing status to "VERIFIED" or "IN_PROGRESS".
`SendBugZillaAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendBugZillaUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendBugZillaAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on BugZilla to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — Exceptionless

Property names	Documented value and constraints
`SendExceptionlessURL`	"URL" option specifies target URL for your Exceptionless installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `api.exceptionless.io/`
`SendExceptionlessPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendExceptionlessSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendExceptionlessPassword`	"API Key" option specifies your account and your project on Exceptionless server. This account/project will be used to submit bug reports. You can create a new API Key in your Exceptionless project profile (chapter 3). Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. See also: Exceptionless setup (chapter 3), Security Considerations (chapter 3).
`SendExceptionlessProxyHost`, `SendExceptionlessProxyLogin`, `SendExceptionlessProxyPassword`, `SendExceptionlessProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendExceptionlessAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on Exceptionless to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — FogBugz

Property names	Documented value and constraints
`SendFogBugzURL`	"URL" option specifies target URL for your ForBugz installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/fogbugz/` or `account.fogbugz.com` Warning: be sure to setup adequate maximum upload file limits in your web-server/FogBugz configuration. Otherwise sending may fail on large bug reports.
`SendFogBugzPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendFogBugzSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendFogBugzLogin`, `SendFogBugzPassword`	"Login" and "Password" options specify your account on FogBugz server. This account will be used to submit bug reports. You can use API token instead of password - leave login field blank in this case. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use FogBugz admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. As alternative - you can always use anonymous submission or BugzScout (chapter 3) - that way you will not store any credentials in your application. See also: FogBugz setup (chapter 3), Security Considerations (chapter 3). Note: it is a good idea to disable e-mail notifications for this account.
`SendFogBugzProxyHost`, `SendFogBugzProxyLogin`, `SendFogBugzProxyPassword`, `SendFogBugzProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendFogBugzBasicAuthLogin`, `SendFogBugzBasicAuthPassword`	"BasicAuth" options specify account details for Basic-Auth type authentication. Usually these fields are blank. Fill them, if you use Basic-Auth on your web server.
`SendFogBugzProject`	"Project" options specifies project name to store bug reports. It's mandatory.
`SendFogBugzOwner`	"Assign to" option specifies owner account name. If this option is empty, all submitted bug reports will be assigned to default account (which is usually a submitter account). If you enter here any account name (it could be the same as "Login" option) - all submitted bug reports will be assigned to this account. Note: this option is ignored, if submitted bug report already exists (submitting a known issue).
`SendFogBugzCategory`	"Category" option specifies category for submitted reports. If this option is empty, all submitted bug report will belong to default category (which is usually "Bug" category). If you enter any category name here - all submitted bug reports will belong to the specified category.
`SendFogBugzArea`	"Area" option specifies area for submitted reports. If this option is empty, all submitted bug report will be assigned to default area (which is usually "Misc" area). If you enter any area name here - all submitted bug reports will be assigned to the specified area.
`SendFogBugzBugIDFieldName`	"BugID field name" option specified name of custom field which EurekaLog can use to store BugID (chapter 8). While name can be a "user-friendly"-name (such as 'Bug ID') - we strongly recommend to use "internal"-name (such as 'plugin_customfields_at_fogcreek_com_bugidv21'). Leave empty if you don't need standalone place to store BugID (chapter 8). It is purely optional, as EurekaLog will use internal BugzScout hash for merging.
`SendFogBugzUseEMail`	"Use e-mail fields" option enables storing client's e-mail as "Correspondent" in ticket.
`SendFogBugzUseComputer`	"Use computer field" option instructs EurekaLog to use first custom field in FogBugz: "Computer". Disable this option, if you've renamed this field and/or use it for other purposes.
`SendFogBugzUseVersion`	"Use version field" option instructs EurekaLog to use second custom field in FogBugz: "Version". Disable this option, if you've renamed this field and/or use it for other purposes.
`SendFogBugzUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "Occurrences" field will be increased. If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to have a lot of hard disk space to store all bug reports.
`SendFogBugzAppendText`	"Append bug report text to description" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendFogBugzUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendFogBugzAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on FogBugz to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (read-only limited access). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — FTP upload

Property names	Documented value and constraints
`SendFTPURL`	"URL" option specifies target URL for file upload. Usually, folder on file server. Do not add here "ftp://" or ":21" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/folder/`
`SendFTPPort`	"Port" option specifies FTP port on file server. It's 21 by default.
`SendFTPPassiveMode`	"Passive mode" option enables so-called "FTP passive mode", which is more friendly to client's firewall/NAT/network configuration than standard (active) mode. FTP can be run in active or passive mode, which determine how the data connection is established. In active mode, the client sends the server the IP address and port number on which the client will listen, and the server initiates the TCP connection. This is a default standard mode. However, in situations where the client is behind a firewall and unable to accept incoming TCP connections, passive mode may be used. In this mode the client sends a PASV command to the server and receives an IP address and port number in return. The client uses these to open the data connection to the server. It's recommended to enable passive mode to bypass client's NAT/firewall.
`SendFTPLogin`, `SendFTPPassword`	"FTP account" options specify your account details on FTP server. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. Create a new special account for bug reporting via this method. See also: Security Considerations (chapter 3). Note: EurekaLog doesn't support SFTP protocol.
`SendFTPProxyHost`, `SendFTPProxyLogin`, `SendFTPProxyPassword`, `SendFTPProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.

TEurekaModuleOptions — GitHub

Property names	Documented value and constraints
`SendGitHubURL`	"URL" option specifies target URL for your GitHub installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `github.com/`
`SendGitHubPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendGitHubSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendGitHubLogin`	"Repo owner" option specifies repository owner on GitHub server. "Project" option (`SendGitHubProject`) specifies repository, which should belong to this account.
`SendGitHubPassword`	"Token" option specifies your account on GitHub server. This account will be used to submit bug reports. You can create a new API Key in your GitHub project profile (chapter 3). Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. See also: GitHub setup (chapter 3), Security Considerations (chapter 3).
`SendGitHubProxyHost`, `SendGitHubProxyLogin`, `SendGitHubProxyPassword`, `SendGitHubProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendGitHubProject`	"Project" options specifies repository name to store bug reports. It's mandatory. Project name is case-insensitive. - If "Repo owner" option is not specified - then repository owner is assumed to be account with access token.
`SendGitHubOpenedStatuses`	"Opened statuses" option specifies which statuses indicate that issue is NEW. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendGitHubClosedStatuses`	"Closed statuses" option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendGitHubUseEnvironment`	"Add environment to labels" option instructs EurekaLog to use add store PC and OS information in labels for the issue. Disable this option to disable this behavior. Please note that EurekaLog will still fill a minimal amount of information to labels (such as BugID (chapter 8)).
`SendGitHubUseVersion`	"Post bugs only for released builds" option instructs EurekaLog to check released versions ("tags") before posting a new issue. Disable this option to always post bugs regardless of version of your application.
`SendGitHubMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendGitHubUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "Weight" field will be increased (if it is available). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
`SendGitHubAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behavior. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendGitHubUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendGitHubAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on GitHub to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — GitLab

Property names	Documented value and constraints
`SendGitLabURL`	"URL" option specifies target URL for your GitLab installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `gitlab.com/`
`SendGitLabPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendGitLabSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendGitLabPassword`	"Token" option specifies your account on GitLab server. This account will be used to submit bug reports. You can create a new API Key in your GitLab project profile (chapter 3). Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. See also: GitLab setup (chapter 3), Security Considerations (chapter 3).
`SendGitLabProxyHost`, `SendGitLabProxyLogin`, `SendGitLabProxyPassword`, `SendGitLabProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendGitLabProject`	"Project" options specifies project name to store bug reports. It's mandatory. Project name is case-insensitive.
`SendGitLabOpenedStatuses`	"Opened statuses" option specifies which statuses indicate that issue is NEW. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendGitLabClosedStatuses`	"Closed statuses" option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendGitLabIssueType`	"Add incidents instead of issues" option instructs EurekaLog to create incidents in GitLab. EurekaLog creates tickets (issues) by default. You may want to switch to incidents to distinguish between manually-entered issues and automatically-entered incidents.
`SendGitLabUseEnvironment`	"Add environment to labels" option instructs EurekaLog to use add store PC and OS information in labels for the issue. Disable this option to disable this behavior. Please note that EurekaLog will still fill a minimal amount of information to labels (such as BugID (chapter 8)).
`SendGitLabUseVersion`	"Post bugs only for released builds" option instructs EurekaLog to check released versions ("tags") before posting a new issue. Disable this option to always post bugs regardless of version of your application.
`SendGitLabMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendGitLabUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "Weight" field will be increased (if it is available). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
`SendGitLabAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behavior. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendGitLabUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendGitLabAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on GitLab to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — HTTP upload

Property names	Documented value and constraints
`SendHTTPURL`	"URL" option specifies target URL for file upload. Usually, it's script name on web server. See description of HTTP upload method (chapter 3) for discussion of upload scripts. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP), path and script name. Example: `www.example.com/folder/upload.php` Warning: be sure to setup adequate maximum upload file limits in your web-server/script configuration. Otherwise sending may fail on large bug reports.
`SendHTTPPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443.
`SendHTTPSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Don't forget to adjust port number, if you change this checkbox.
`SendHTTPMethod`	"Method" option specifies type of HTTP request being sent. Default is 'POST'. Please, refer to your receiving side (e.g. script at the specified URL) to learn which method should be used.
`SendHTTPAuthLogin`, `SendHTTPAuthPassword`	"BasicAuth" options specify account details for Basic-Auth type authentication. Usually these fields are blank. Fill them, if you use Basic-Auth on your web server. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. Create a new special account for bug reporting via this method. See also: Security Considerations (chapter 3).
`SendHTTPProxyHost`, `SendHTTPProxyLogin`, `SendHTTPProxyPassword`, `SendHTTPProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendHTTPHeaders`	"HTTP Headers" option specifies additional HTTP headers to pass to the server on the specified URL. Each header must be placed on standalone line. Field name and value are separated by the ': ' ('colon' and 'space') characters. Important Note: if you override the Content-Type header with the application/x-www-form-urlencoded value - EurekaLog will send web fields, but will not upload any files. That is because application/x-www-form-urlencoded does not support file attaches. If you are going to use application/x-www-form-urlencoded - you will need to upload files by other means. A practical example can be found HTTP upload to Jira (chapter 3).
`SendHTTPFields`	"HTML Fields" option specifies static web-form fields to send. Each field must be placed on standalone line. Field name and value are separated by the '=' ('equal') character. Typically you would use OnCustomWebFieldsRequest event handler to set up web fields. However, if you have bunch of static fields (such as project ID, etc.) - you can set those here.

TEurekaModuleOptions — Jira/BitBucket

Property names	Documented value and constraints
`SendJIRAURL`	"URL" option specifies target URL for your Jira installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/jira/` Warning: be sure to setup adequate maximum upload file limits in your web-server/ira configuration. Otherwise sending may fail on large bug reports.
`SendJIRAPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendJIRASSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendJIRALogin`, `SendJIRAPassword`	"Login" and "API Token" options specify your account on Jira server. This account will be used to submit bug reports. - When using passwords (not API Tokens): do not specify e-mail or full user name as login, use only username. You can find your username in your Jira profile. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use Jira admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: Jira setup (chapter 3), Security Considerations (chapter 3). Note: it is a good idea to disable e-mail notifications for this account.
`SendJIRAProxyHost`, `SendJIRAProxyLogin`, `SendJIRAProxyPassword`, `SendJIRAProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendJIRAProject`	"Project" options specifies project name to store bug reports. It's mandatory. Project name is case-insensitive, do not specify project key as name.
`SendJIRAIssueType`	"Issue type" option specifies issue type to create. Mandatory. Default is "Bug".
`SendJIRAOwner`	"Assign to" option specifies owner account name. If this option is empty, all submitted bug reports will be assigned to default account (configured in Jira options). If you enter here any account name - all submitted bug reports will be assigned to this account. Do not specify full user name as login, use only username. Note: this option is ignored, if submitted bug report already exists (submitting known issue).
`SendJIRAComponent`	"Component" option specifies component for submitted reports. It's optional.
`SendJIRACountFieldName`	""Count" field name" option specifies name of custom field, which EurekaLog will use for bug report counting. By default, Jira doesn't have any "occurrences" or "count" fields, so you can't know how many times bug has occurred. To workaround this problem, you can create a custom field in Jira configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs. Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide (chapter 3).
`SendJIRAEMailFieldName`	""E-mail" field name" option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, Jira doesn't have such field. You can either create a custom field in Jira configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach). Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide (chapter 3).
`SendJIRABugIDFieldName`	""BugID" field name" option specifies name of custom field, which EurekaLog will use to store BugID (chapter 8). By default, Jira doesn't have such field. You can create a custom field in Jira configuration, which you will use for this purpose. When field is specified - it will be used by EurekaLog to search/merge reports. Otherwise title (summary) is used for merging. Note: we highly recommend to create and use this field. Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide (chapter 3).
`SendJIRAOpenedStatuses`	"Opened statuses" option specifies which statuses indicate that issue is NEW. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendJIRAClosedStatuses`	"Closed statuses" option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendJIRAMaxTextSize`	"Max. text field size" option will cut all text fields (description, summary, comment, etc.) to the specified value. The limit is set in characters. Set this option to 0 to remove limits. This option must match your Jira configuration. If you set this value to be larger than specified in your Jira configuration - then sending report may fail. Note: not all Jira versions have this setting. If your Jira installation do not have such setting (allow unlimited amount of text) - then remove the limit by setting this option to 0.
`SendJIRAUseEnvironment`	"Use/fill "Environment" field" option instructs EurekaLog to use "Environment" field in Jira to store PC and OS information. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog.
`SendJIRAUseVersion`	"Use/fill version field" option instructs EurekaLog to use "Affect Version" field in Jira. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog. - You must enter valid versions into Jira's configuration. You also need to store version information in your executables to fill this field. - A project version will be used during sending. The version is extracted from version information of your project's executable. - Exception's module version is not used for sending (unless exception's module matches project's module).
`SendJIRARequireReleased`	"Require "Released" status" option will perform version search only on released versions. Otherwise non-released versions will also be used in search. Because bug tracker may create versions in an arbitrary format (like "Version 1" or "7.3 hotfix 2"), and application uses 4 numbers format (like "7.3.2.0") - EurekaLog has to perform heuristic search. Therefore, it is a good idea to minimize chances of false-positive matches by utilizing additional information, like released status. Note: obsolete/archieved versions are always excluded from version search.
`SendJIRAMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendJIRAUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
`SendJIRAAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendJIRAUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendJIRAAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on Jira to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — Shell send

Property names	Documented value and constraints
`SendShellTarget`	"Address(es)" option specifies target e-mail address to send bug report to. Specify here your e-mail address for bug reports harvesting. Multiple e-mail addresses are allowed (separate them with "," or ";"), but this is usually not a good idea, since not every e-mail client software support this.
`SendShellSubject`	"E-mail subject" option specifies header (subject) for all sent bug reports. You can specify generic static text here (like 'Bug report for Project X') or use a %tag% to generate dynamic subject to distinguish one bug report from another. See using variables (chapter 25) for more info.
`SendShellMessage`	"E-mail message" option is optional text of e-mail message (body). You can enter here any text, use variables or just leave this field empty. Bug report text will appear here automatically.
`SendShellUseShellExecute`	"Use ShellExecuteEx" option defines which method should application use to run mailto links. Checked: use ShellExecuteEx function to open mailto link. Unchecked: use CreateProcess function to open mailto link. However, when using CreateProcess function - application must manually resolve mailto protocol registration to obtain executable of mail application. This may or may not be the same application as used by ShellExecuteEx function.
`SendShellUTF8`	"UTF-8 encode" option encodes subject and message in UTF-8 encoding (unicode). If this option is unchecked - these strings will be send as ANSI (in current ANSI encoding). Check this option to send extended characters outside of current ANSI page. Uncheck this option to use old and compatible ANSI encoding. The issue with that option is that not every e-mail client supports UTF-8 in mailto protocol. If e-mail client doesn't support UTF-8 and you've checked this option - resulting mail will contain non-English text in invalid encoding. For example: Note: some e-mail clients may support or don't support UTF-8 in mailto protocol depending on their settings. For example, Outlook have "Allow UTF-8 support for mailto: protocol" option, which is located in "Advanced" section of Outlook's options: Note: enabling "UTF-8" option may decrease limit on maximum e-mail length due to multi-byte character encoding.
`SendShellEncode`	"Message encode" option enables %-encoding for some characters, as required by mailto protocol specification. You can uncheck this option, if you have some problems with e-mail clients.

TEurekaModuleOptions — Mantis

Property names	Documented value and constraints
`SendMantisURL`	"URL" option specifies target URL for your Mantis installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/mantis/` Warning: be sure to setup adequate maximum upload file limits in your web-server/Mantis configuration. Otherwise sending may fail on large bug reports.
`SendMantisPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendMantisSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendMantisLogin`, `SendMantisPassword`	"Login" and "Password" options specify your account on Mantis server. This account will be used to submit bug reports. Do not specify e-mail or full user name as login, use only user name. You can use API token instead of password - however, you still have to supply a valid login (user name). Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use Mantis admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: Mantis setup (chapter 3), Security Considerations (chapter 3). Note: it is a good idea to disable e-mail notifications for this account. It is a good idea to make this account "protected".
`SendMantisBasicAuthLogin`, `SendMantisBasicAuthPassword`	"BasicAuth" options specify account details for Basic-Auth type authentication. Usually these fields are blank. Fill them, if you use Basic-Auth on your web server.
`SendMantisProxyHost`, `SendMantisProxyLogin`, `SendMantisProxyPassword`, `SendMantisProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendMantisProject`	"Project" options specifies project name to store bug reports. It's mandatory.
`SendMantisOwner`	"Assign to" option specifies owner account name. If this option is empty, all submitted bug reports will be unassigned (and their state will be "new"). If you enter here any account name (it could be the same as "Login" option) - all submitted bug reports will be assigned to this account (and their state will be "assigned"). Note: this option is ignored, if submitted bug report already exists (submitting a known issue).
`SendMantisCategory`	"Category" option specifies category for submitted reports. It can be optional or mandatory - it depends on your Mantis version and project configuration.
`SendMantisCountFieldName`	""Count" field name" option specifies name of custom field, which EurekaLog will use for bug report counting. By default, Mantis doesn't have any "occurrences" or "count" fields, so you can't know how many times bug has occurred. To workaround this problem, you can create a custom field in Mantis configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs. Note: we highly recommend to create and use this field.
`SendMantisEMailFieldName`	""E-mail" field name" option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, Mantis doesn't have such field. You can either create a custom field in Mantis configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach).
`SendMantisBugIDFieldName`	""BugID" field name" option specifies name of custom field, which EurekaLog will use to store BugID (chapter 8). By default, Mantis doesn't have such field. You can create a custom field in Mantis configuration, which you will use for this purpose. When field is specified - it will be used by EurekaLog to search/merge reports. Otherwise title (summary) is used for merging. Note: we highly recommend to create and use this field.
`SendMantisInProgressStatuses`	"In progress statuses" option specifies which statuses indicate that issue is IN PROGRESS. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendMantisClosedStatuses`	"Closed statuses" option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendMantisUseVersion`	"Use/fill "Product version" field" option instructs EurekaLog to use "Product Version" field in Mantis. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog. - You must enter valid versions into Mantis configuration. You also need to store version information in your executables to fill this field. - A project version will be used during sending. The version is extracted from version information of your project's executable. - Exception's module version is not used for sending (unless exception's module matches project's module).
`SendMantisRequireReleased`	"Require "Released" status" option will perform version search only on released versions. Otherwise non-released versions will also be used in search. Because bug tracker may create versions in an arbitrary format (like "Version 1" or "7.3 hotfix 2"), and application uses 4 numbers format (like "7.3.2.0") - EurekaLog has to perform heuristic search. Therefore, it is a good idea to minimize chances of false-positive matches by utilizing additional information, like released status. Note: obsolete/archieved versions are always excluded from version search.
`SendMantisMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendMantisUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports. - you can also stop collecting files by changing status to "confirmed" or "acknowledged".
`SendMantisAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Additional information" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendMantisUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendMantisAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on Mantis to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — MAPI

Property names	Documented value and constraints
`SendMAPITarget`	"Address(es)" option specifies target e-mail address to send bug report to. Specify here your e-mail address for bug reports harvesting. Multiple e-mail addresses are allowed (separate them with "," or ";").
`SendMAPISubject`	"E-mail subject" option specifies header (subject) for all sent bug reports. You can specify generic static text here (like 'Bug report for Project X') or use a %tag% to generate dynamic subject to distinguish one bug report from another. See using variables (chapter 25) for more info.
`SendMAPIMessage`	"E-mail message" option is optional text of e-mail message (body). You can enter here any text, use variables or just leave this field empty.
`SendMAPIAppendLogs`	"Append bug report text in the message text" option appends bug report text to the e-mail message (body). If e-mail body is empty - e-mail will consist of bug report text only. If you've entered non-null text - the first will be your text, the next will be bug report text. Note: checking this option will not disable bug report file upload. File will still be attached.

TEurekaModuleOptions — Redmine

Property names	Documented value and constraints
`SendRedmineURL`	"URL" option specifies target URL for your Redmine installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/Redmine/` Warning: be sure to setup adequate maximum upload file limits in your web-server/Redmine configuration. Otherwise sending may fail on large bug reports.
`SendRedminePort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 3000 (for local installation). For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendRedmineSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendRedmineLogin`, `SendRedminePassword`	"Login" and "Password" options specify your account (login) on Redmine server. This account will be used to submit bug reports. Do not specify e-mail or full user name as login, use only username. You can find your username in your Redmine profile. You can use API token instead of password - leave login field blank in this case. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use Redmine admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: Redmine setup (chapter 3), Security Considerations (chapter 3). - Your login / password pair will be replaced with API key once you click "Connect" button. You can remove API key and re-enter login / password pair. Important: unfortunately, Redmine does not allow regular users to obtain list of users and custom fields. Therefore, you have to create administrator user if you want to use custom fields.
`SendRedmineProxyHost`, `SendRedmineProxyLogin`, `SendRedmineProxyPassword`, `SendRedmineProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendRedmineProject`	"Project" options specifies project name to store bug reports. It's mandatory. Project name is case-insensitive, do not specify project key as name.
`SendRedmineTracker`	"Tracker" option specifies tracker type for the issue. Mandatory. Default is "Bug".
`SendRedmineCategory`	"Category" option specifies category for submitted reports. It's optional.
`SendRedmineCountFieldName`	""Count" field name" option specifies name of custom field, which EurekaLog will use for bug report counting. By default, Redmine doesn't have any "occurrences" or "count" fields, so you can't know how many times bug has occurred. To workaround this problem, you can create a custom field in Redmine configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs. Important: unfortunately, Redmine does not allow regular users to obtain list of users and custom fields. Therefore, you have to create administrator user if you want to use custom fields.
`SendRedmineEMailFieldName`	""E-mail" field name" option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, Redmine doesn't have such field. You can either create a custom field in Redmine configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach). Important: unfortunately, Redmine does not allow regular users to obtain list of users and custom fields. Therefore, you have to create administrator user if you want to use custom fields.
`SendRedmineBugIDFieldName`	""BugID" field name" option specifies name of custom field, which EurekaLog will use to store BugID (chapter 8). By default, Redmine doesn't have such field. You can create a custom field in Redmine configuration, which you will use for this purpose. When field is specified - it will be used by EurekaLog to search/merge reports. Otherwise title (summary) is used for merging. Note: we highly recommend to create and use this field. Important:
`SendRedmineVersionFieldName`	""Version" field name" option specifies name of custom field, which EurekaLog will use to store version of crashed module. By default, Redmine doesn't have such field. You can either create a custom field in Redmine configuration, which you will use for this purpose; or you can simply extract version from bug report (file attach). Important: unfortunately, Redmine does not allow regular users to obtain list of users and custom fields. Therefore, you have to create administrator user if you want to use custom fields. Note: obsolete/archieved versions are always excluded from version search.
`SendRedmineMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendRedmineOpenedStatuses`	"Opened statuses" option specifies which statuses indicate that issue is NEW. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendRedmineClosedStatuses`	"Closed statuses" option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.
`SendRedmineUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
`SendRedmineAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendRedmineUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendRedmineAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on Redmine to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — Simple MAPI

Property names	Documented value and constraints
`SendSMAPITarget`	"Address(es)" option specifies target e-mail address to send bug report to. Specify here your e-mail address for bug reports harvesting. Multiple e-mail addresses are allowed (separate them with "," or ";").
`SendSMAPISubject`	"E-mail subject" option specifies header (subject) for all sent bug reports. You can specify generic static text here (like 'Bug report for Project X') or use a %tag% to generate dynamic subject to distinguish one bug report from another. See using variables (chapter 25) for more info.
`SendSMAPIMessage`	"E-mail message" option is optional text of e-mail message (body). You can enter here any text, use variables or just leave this field empty.
`SendSMAPIAppendLogs`	"Append bug report text in the message text" option appends bug report text to the e-mail message (body). If e-mail body is empty - e-mail will consist of bug report text only. If you've entered non-null text - the first will be your text, the next will be bug report text. Note: checking this option will not disable bug report file upload. File will still be attached.

TEurekaModuleOptions — SMTP client

Property names	Documented value and constraints
`SendSMTPClientTarget`	"Address(es)" option specifies target e-mail address to send bug report to. Specify here your e-mail address for bug reports harvesting. Multiple e-mail addresses are allowed (separate them with "," or ";").
`SendSMTPClientSubject`	"E-mail subject" option specifies header (subject) for all sent bug reports. You can specify generic static text here (like 'Bug report for Project X') or use a %tag% to generate dynamic subject to distinguish one bug report from another. See using variables (chapter 25) for more info.
`SendSMTPClientMessage`	"E-mail message" option is optional text of e-mail message (body). You can enter here any text, use variables or just leave this field empty.
`SendSMTPClientAppendLogs`	"Append bug report text in the message text" option appends bug report text to the e-mail message (body). If e-mail body is empty - e-mail will consist of bug report text only. If you've entered non-null text - the first will be your text, the next will be bug report text. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendSMTPClientFrom`	"From field" option specifies your e-mail address. It's your real e-mail account on e-mail server, which will be used to send bug reports. It can be the same as "Address(es)" option, but it doesn't have to. If you specify e-mail only (e.g. no user name is specified) - then EurekaLog will use user name of currently logged in user account. This is useful if you want to quickly sort/scan incoming bug reports for your users (e.g. if two reports come from same person). This will force EurekaLog to always use "My Application" as fixed user name when sending bug reports.
`SendSMTPClientUseRealEMail`	"Use user-supplied e-mail" option allows you to substitute your real e-mail address with customer's e-mail (which can be set via some error dialogs (chapter 24) or SetUserEMail (appendix A, SetUserEmail) function). If you turn this option on - you will see customer's e-mail in FROM field in bug reports. This is convenient. Important: usually you need to keep this option unchecked, since most e-mail servers will not allow you to send e-mails as from other people.
`SendSMTPClientHost`	"Host / server" specifies the SMTP server supplied by your mail provider or administrator. Do not derive it by guessing from the address's domain. For the synthetic address `account@example.com`, names such as `smtp.example.com` illustrate the format only; they are not a discovered or configured server.
`SendSMTPClientPort`	"Port" option specified TCP port number. Again, refer to your e-mail server's support/help to get this value. Typical values are 25, 587 and 465.
`SendSMTPClientSSL`, `SendSMTPClientTLS`	"SSL" and "TLS" options enabled secure mode for e-mail server. Check one of these options only if your e-mail server requires it. Please, see What's the difference between SSL and TLS send modes? (chapter 3) to know more about these mode differences. Usually, it's best to turn on "TLS" checkbox, even if your e-mail server doesn't require it.
`SendSMTPClientLogin`	"UserID / login" specifies the SMTP authentication login supplied by your mail provider or administrator. It may be the complete address or its local part: for the synthetic address `account@example.com`, examples are `account@example.com` and `account`. Use the value required by the server.
`SendSMTPClientPassword`	"Password" option is your password on e-mail server. Currently EurekaLog supports AUTH LOGIN and AUTH PLAIN authentication methods. Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use your personal e-mail for this. Create a new special account for bug reporting via this method (and be sure to protect it against e-mail change or hi-jacking). If you are using two-factor auth (recommended) - then create a new application password for your application. See also: Security Considerations (chapter 3).

TEurekaModuleOptions — SMTP server

Property names	Documented value and constraints
`SendSMTPServerTarget`	"Address(es)" option specifies target e-mail address to send bug report to. Specify here your e-mail address for bug reports harvesting. Multiple e-mail addresses are allowed (separate them with "," or ";").
`SendSMTPServerSubject`	"E-mail subject" option specifies header (subject) for all sent bug reports. You can specify generic static text here (like 'Bug report for Project X') or use a %tag% to generate dynamic subject to distinguish one bug report from another. See using variables (chapter 25) for more info.
`SendSMTPServerMessage`	"E-mail message" option is optional text of e-mail message (body). You can enter here any text, use variables or just leave this field empty.
`SendSMTPServerAppendLogs`	"Append bug report text in the message text" option appends bug report text to the e-mail message (body). If e-mail body is empty - e-mail will consist of bug report text only. If you've entered non-null text - the first will be your text, the next will be bug report text. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendSMTPServerFrom`	"From field" option specifies your e-mail address. It's can be any valid e-mail address, which will be used as "sender" to send bug reports. It can be the same as "Address(es)" option, but it doesn't have to. This doesn't have to be real e-mail account. It can be anything. If you specify e-mail only (e.g. no user name is specified) - then EurekaLog will use user name of currently logged in user account. This is useful if you want to quickly sort/scan incoming bug reports for your users (e.g. if two reports come from same person). This will force EurekaLog to always use "My Application" as fixed user name when sending bug reports.
`SendSMTPServerUseRealEMail`	"Use user-supplied e-mail" option allows you to substitute your real e-mail address with customer's e-mail (which can be set via some error dialogs (chapter 24) or SetUserEMail (appendix A, SetUserEmail) function). If you turn this option on - you will see customer's e-mail in FROM field in bug reports. This is convenient. Usually, you want to keep this option checked. Important Note: you can use CurrentEurekaLogOptions.CustomHELO option to alter name to be passed to HELO/EHLO SMTP command.

TEurekaModuleOptions — YouTrack

Property names	Documented value and constraints
`SendYouTrackURL`	"URL" option specifies target URL for your YouTrack installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: `www.example.com/youtrack/` Warning: be sure to setup adequate maximum upload file limits in your web-server/YouTrack configuration. Otherwise sending may fail on large bug reports.
`SendYouTrackPort`	"Port" option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.
`SendYouTrackSSL`	"SSL / TLS" option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.
`SendYouTrackPassword`	"Token" option specifies your account on YouTrack server. This account will be used to submit bug reports. Do not specify e-mail, login, or full user name, use only API tokens. You can create a new API token in your YouTrack profile (chapter 3). Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use YouTrack admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: YouTrack setup (chapter 3), Security Considerations (chapter 3). Note: it is a good idea to disable e-mail notifications for this account.
`SendYouTrackProxyHost`, `SendYouTrackProxyLogin`, `SendYouTrackProxyPassword`, `SendYouTrackProxyPort`	"Proxy" options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.
`SendYouTrackProject`	"Project" options specifies project name to store bug reports. It's mandatory. Project name is case-insensitive, do not specify project key as name.
`SendYouTrackIssueType`	"Issue type" option specifies issue type to create. Mandatory. Default is "Bug".
`SendYouTrackOwner`	"Assign to" option specifies owner account name. If this option is empty, all submitted bug reports will be assigned to a default account (configured in YouTrack options). If you enter here any account name - all submitted bug reports will be assigned to this account. Note: this option is ignored, if submitted bug report already exists (submitting known issue).
`SendYouTrackComponent`	"Sub system" option specifies sub system (component) for submitted reports. It's optional.
`SendYouTrackCountFieldName`	""Count" field name" option specifies name of custom field, which EurekaLog will use for bug report counting. While YouTrack have "occurrences"/"count" field: "votes", but you can not alter this field arbitrarily. To workaround this problem, you can create a custom field in YouTrack configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs. Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See YouTrack configuration guide (chapter 3).
`SendYouTrackEMailFieldName`	""E-mail" field name" option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, YouTrack doesn't have such field. You can either create a custom field in YouTrack configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach). Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See YouTrack configuration guide (chapter 3).
`SendYouTrackBugIDFieldName`	""BugID" field name" option specifies name of custom field, which EurekaLog will use to store BugID (chapter 8). By default, YouTrack doesn't have such field. You can create a custom field in YouTrack configuration, which you will use for this purpose. When field is specified - it will be used by EurekaLog to search/merge reports. Otherwise title (summary) is used for merging. Note: we highly recommend to create and use this field. Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See YouTrack configuration guide (chapter 3).
`SendYouTrackUseVersion`	"Use/fill version field" option instructs EurekaLog to use "Affect Version" field in YouTrack. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog. - You must enter valid versions into YouTrack's configuration. You also need to store version information in your executables to fill this field. - A project version will be used during sending. The version is extracted from version information of your project's executable. - Exception's module version is not used for sending (unless exception's module matches project's module).
`SendYouTrackRequireReleased`	"Require "Released" status" option will perform version search only on released versions. Otherwise non-released versions will also be used in search. Because bug tracker may create versions in an arbitrary format (like "Version 1" or "7.3 hotfix 2"), and application uses 4 numbers format (like "7.3.2.0") - EurekaLog has to perform heuristic search. Therefore, it is a good idea to minimize chances of false-positive matches by utilizing additional information, like released status. Note: obsolete/archieved versions are always excluded from version search.
`SendYouTrackMinVersion`	"Search match up to N numbers" option specifies how version search is performed. - Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3". - Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7"). We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration. Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.
`SendYouTrackUploadFilesForDups`	"Upload bug report files for duplicates until bug is closed" option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID (chapter 8)) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue. - if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
`SendYouTrackAppendText`	"Append bug report text to additional information" option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour. Note: checking this option will not disable bug report file upload. File will still be attached.
`SendYouTrackUseCallStackAsBugReport`	"Append only call stack instead of full report" option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).
`SendYouTrackAllowLinks`	"Append bug opening link to "Success" message" option will add a link to view bug report on YouTrack to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required). This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers. Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

TEurekaModuleOptions — Sending options page

Property names Documented value and constraints

AttachedFiles "Additional files" option specifies additional files to include into sent bug report. You can use ';' to separate files. You can use environment variables (chapter 25) to access special folders. You can use relative file paths to access application's folder (useful for portable applications). For example: 'Configs\Master.ini;%APPDATA%\MySoftware\Config.ini' - this value will attach two files. One file is Master.ini file in Configs subfolder of exe's directory. Second file will be Config.ini file from roaming application folder. You can also specify this option at run-time. Or you can use OnZippedFilesRequest (appendix B, TELEvZippedFilesRequestMeth) event handlers. Please note that this option will include files inside bug report when "Pack send files into single file" option is checked. To attach more files near bug report - use OnAttachedFilesRequest (appendix B, TELEvAttachedFilesRequestMeth) event. Note: current application directory have no effect on relative paths in this option. All relative paths are always resolved with application folder.

ZipPassword Pack with password encrypts the .elp ZIP archive using the specified password. Archive encryption protects the file; TLS protects the network connection. SSL/TLS protects transport only: it does not encrypt an archive at rest or after delivery, and is not a substitute for a ZIP password when archive encryption is required. The password is present in the executable that must use it, so this is not full protection from someone who has that executable. This is separate from Debug information encryption password (also known as Data protection password in older terminology), which protects symbol names—not every report field or attachment. Chapter 4 explains both Viewer password layers. Viewer can remember passwords locally under HKEY_CURRENT_USER\Software\EurekaLab\Viewer\7.0\Passwords and ...\Hashes, identified by project; protect that user profile.

Property names	Documented value and constraints
`AttachedFiles`	"Additional files" option specifies additional files to include into sent bug report. You can use ';' to separate files. You can use environment variables (chapter 25) to access special folders. You can use relative file paths to access application's folder (useful for portable applications). For example: 'Configs\Master.ini;%APPDATA%\MySoftware\Config.ini' - this value will attach two files. One file is Master.ini file in Configs subfolder of exe's directory. Second file will be Config.ini file from roaming application folder. You can also specify this option at run-time. Or you can use OnZippedFilesRequest (appendix B, TELEvZippedFilesRequestMeth) event handlers. Please note that this option will include files inside bug report when "Pack send files into single file" option is checked. To attach more files near bug report - use OnAttachedFilesRequest (appendix B, TELEvAttachedFilesRequestMeth) event. Note: current application directory have no effect on relative paths in this option. All relative paths are always resolved with application folder.
`ZipPassword`	Pack with password encrypts the `.elp` ZIP archive using the specified password. Archive encryption protects the file; TLS protects the network connection. SSL/TLS protects transport only: it does not encrypt an archive at rest or after delivery, and is not a substitute for a ZIP password when archive encryption is required. The password is present in the executable that must use it, so this is not full protection from someone who has that executable. This is separate from Debug information encryption password (also known as Data protection password in older terminology), which protects symbol names—not every report field or attachment. Chapter 4 explains both Viewer password layers. Viewer can remember passwords locally under `HKEY_CURRENT_USER\Software\EurekaLab\Viewer\7.0\Passwords` and `...\Hashes`, identified by project; protect that user profile.