There are two things to note when using EurekaLog to send exception information to CodeSite. The first is the fact that EurekaLog behaves slightly different than the rest of the supported third-party products (more on this below). The second is that its setup is very configurable and is similar to the JCLDebugHandler for the purposes of using it with CodeSite.

Simply drop a TEurekaLog component onto your form, we do not need to include either a CodeSite or CodeSiteEx component.  See the screenshot below:

A similarity between EurekaLog and the JCLDebugHandler is the complete independence from the TcsxErrorTrapControl. Thus when using EurekaLog, there are no CSX.INC settings to change.

EurekaLog is its own entity that redirects its messages to CodeSite, allowing it to work equally well with CodeSite as with CodeSiteEx, in addition to its email, web, and LogFile output.

After dropping the EurekaLog component on our main form, we have to add code to its OnExceptionNotify event (the amount of code varies with the output we desire) to redirect its output to a specific destination; in our case, CodeSite.

To retrieve the call stack for an exception, we would do the following:

Note: for CodeSite version 2, the line should read CodeSite.SendStringList('Call Stack:', CallStack);

When we run this code, the following error message is still displayed (note the different error window - this appears when EurekaLog handles the exception rather than Delphi):

Let's check what is sent to the CodeSite Viewer.  Click on the thumbnail to see the CodeSite Viewer's contents full size.

The Inspector Pane displays the full call stack, including address, module, unit, class, procedure/method, and line number.

If that isn't enough information for you, EurekaLog allows us to retrieve a LOT more information.  Rather than sending the Call Stack to CodeSite, we can grab the entire exception log text and send it instead.  Changing our existing code to this:

... will instruct EurekaLog to dump its entire exception log to the CodeSite viewer.

Let's check what is sent to the CodeSite Viewer.  Click on the thumbnail to see the CodeSite Viewer's contents full size.

This time the Inspector Pane shows a wealth of information conveniently grouped into the categories "EurekaLog version", "Application", "Exception", "Active Controls", "Computer", "Operating System", "Network", "Call Stack", "Modules", and "Registers".

You may notice that no EnterMethod and ExitMethod messages are in the viewer.  That is because we did not include the CSObjectEx object and the TraceMethod call.  Changing our form to this:

And updating our source code as follows:

... will result in the following being sent to the CodeSite Viewer (click on the thumbnail to see the Viewer's contents full size):

OK. This is probably NOT what you might expect to see. Rather than the exception information appearing between the EnterMethod and ExitMethod lines, it appears 'outside' of the pair. Regrettably, the existing design of EurekaLog prevents it from working within the TcsxErrorTrapControl like the other supported third party libraries.  This being the case, it is out of CodeSiteEx's control exactly when EurekaLog sends its exception log output to CodeSite. In our example, while EurekaLog trapped the exception properly, it would seem that its OnExceptionNotify event redirects the exception output AFTER CodeSiteEx's internal exception notification system has kicked in and closed the TraceMethod call.

Nevertheless, EurekaLog is an extremely powerful debugging tool that can send an enormous amount of data to CodeSite when exceptions occur.