Root > Integral parts > Options > Advanced page > Code page > Hooks page

Hooks page

Previous pageReturn to chapter overviewNext page   

This is "Advanced/Code/Hooks" page in EurekaLog project's options.



Hooks code options


Each option includes hooks for specific cases (i.e. Pascal units). You should enable option to install hook (and invoke EurekaLog) or disable option to remove hook. See also: External tools options page.


"Console" - for console applications.
"VCL Forms" - for applications with Forms or VCL.Forms unit.
"Control Panel" - for applications with CtlPanel unit.
"NT Service" - for applications with SvcMgr unit.
"CGI" - for applications with CGIApp unit.
"ISAPI" - for applications with ISAPIApp unit.
"IntraWeb" - for applications with IntraWeb units.
"CLX" - for applications with QForms unit.
"FMX" - for applications with FMX.Forms unit.


Usually these settings are set by selecting type of your application. You rarely need to change them.


Additional hooks are not tied to specific application type and may be used in any application. However, all of these options installs code hook - thus, they may be incompatible with some EXE cryptors, packers, protectors. Additional hooks may be customized by you depending on your needs.


1. "Auto-handle TThread exceptions" - option enables backward-compatible EurekaLog 6 behavior for threads. When you enable this option - EurekaLog will automatically handle exception in TThread. Default behavior is not to handle exception, but allow it to be saved in TThread.FatalException property, which can be analyzed/handled by caller thread.


Warning: enabling this option may result in multiple error dialogs at the same time (if several exception occur in multiple threads).


Note: it's not recommended to use this option. You should implement proper error handling for threads instead.



2. "DLL callbacks to host" option allows DLL to use exception manager from main module. This option is used with "Lightweight DLL" profile when you need to call methods from exception manager (since there is no exception manager in DLL).


Warning: do not use this option for "Standalone DLL" profile or any other profiles except "Lightweight DLL".


This options is turned on automatically for lightweight DLL profile. Usually you don't need to manage it manually.


This option can be used without EurekaLog in current module.


For more information: see using EurekaLog with DLLs.



3. "Map OS errors to exception classes" option converts all exceptions of EOSError class to (new) exception classes (from EMapWin32 unit). For example, there will be EOSAccessDenied exception raised instead of EOSError with ErrorCode = 5. This option will replace exception classes globally in all application. Old filtering code (i.e. "on E: EOSError do") should still work, because all new exception classes descend from EOSError. You can use this option to create exception filters for OS errors.


It's recommended to keep this option enabled.


This option also can be used without EurekaLog in current module.



4. "Fix TObject.SafeCallException for hardware exceptions" option fixes bug from Quality Central bug report #81725.


TObject.SafeCallException works only for Delphi exceptions. If there is a hardware exception raised in safecall-method (like access violation or div by zero) - TObject.SafeCallException will be ignored, instead the fixed code of E_UNEXPECTED ($8000FFFF) will be used.


With current implementation it is impossible to alter this behaviour except of using ugly workarounds.


The problem seems to be in System._HandleAutoException routine. This routine does not call TObject.SafeCallException if exception in question is not Delphi exception.


Enable this option for COM applications or any other applications which use safecall-exceptions.


This option can be used without EurekaLog in current module.



This option has effect only for Win32 platform. It has no effect for 64bit code or MacOS.
You probably would want to enable "Handle every SafeCall exception" option for COM applications too.



See also:

Send feedback... Build date: 2020-01-21
Last edited: 2019-06-17
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: