1. From installation to your first useful report

Your first milestone is not a new component on a form. It is a saved report that identifies a deliberate exception in your own source, from the executable you actually built. Start with a small Windows VCL application, keep delivery disabled, and prove that local reporting works before adding threads, DLLs, leak checks, or a remote issue tracker.

1.1 Choose the installation that fits your compiler

Record the IDE product, its maintenance update, the Delphi or C++Builder personality, and the application target platform. IDE bitness and application bitness are different: a 32-bit IDE can build a Win64 application. EurekaLog installs separate precompiled files for each supported IDE and platform; changing a search path cannot make one compiler's DCUs compatible with another compiler.

Use these distinctions when selecting an installer:

EurekaLog 7 supports Windows Win32 and Win64, Delphi 5 onward, and C++Builder 2006 onward, subject to the compiler and project-type restrictions in this book. Older Delphi 3/4 and C++Builder 5/6 references concern earlier EurekaLog generations. Support for the 64-bit IDE is documented from RAD Studio 12.3; select its corresponding installed packages rather than reusing 32-bit IDE packages. Do not interpret a modern platform name in a directory as proof that all exception or symbol features are supported there.

The historical limited-edition guide distinguishes Turbo Professional, Starter, and the listed Community editions, which accept the IDE expert, from Turbo Explorer, which rejects third-party experts, and Delphi 7 Personal, which lacks packages required by the expert. Those latter cases need manual preparation and post-processing (section 2.6), not repeated attempts to register an unavailable extension. This is a technical distinction, not a statement of current license terms.

1.2 Install, activate, and register the expert

1. Close every Delphi, C++Builder, and RAD Studio instance. Run the chosen EurekaLog installer with administrator rights. If it requests removal of an older installation, preserve your configuration and rollback material first (section 2.9), then follow that removal step.
2. If installation activation is requested, either select Activate license automatically and enter the credentials for the product account, or supply the installer-specific .ellicense file obtained for that exact installer. The account password is not the installation key. Manual keys are time-limited; obtain a fresh one when an old key is rejected. You can select the file in the installer, or place it beside the installer with the same basename and the .ellicense extension. Trial and Tools installers do not require this installation key.
3. On the component selection page, confirm that your IDE and personality are visible and checked. Complete installation. A common source tree does not replace the per-IDE compiled files.
4. Start the IDE under the account you normally use. Open a project and look for Project > EurekaLog options; some versions call it EurekaLog project options.

If the menu is missing, close the IDE and run Start > EurekaLog > Manage EurekaLog in IDEs, or Bin\ManageProfiles.exe in the installation folder. Expand the correct IDE and select Register EurekaLog 7 (recommended). Older Manage versions label the equivalent choice EurekaLog 7 with IDE expert. Restart the IDE.

Registration is per user. For a non-administrator developer, installation and the one-time copying of runtime packages are performed by an administrator; then run Manage again under the developer account and register that IDE there. Manage under a limited account performs per-user changes without copying BPL files into protected Windows directories. Keeping the IDE permanently elevated is not the solution.

Distinguish these failures before reinstalling:

• The IDE is listed, but DCUs are not installed and registration is disabled: rerun the matching installer and select that IDE's files.
• The IDE is not listed at all: the installer discovers IDE roots and personalities through registry entries. Repair/reinstall the IDE to restore them, or use the explicit installation route in section 2.6 for an intentionally invisible or virtualized IDE. On 64-bit Windows, registry views and the Wow6432Node view matter; do not add guessed registry entries.
• An entry point or unit-version error appears: check the exact IDE maintenance build and EurekaLog package version. Registration cannot repair binary incompatibility. See section 2.9.
• The IDE and installer run in different application sandboxes: run them in the same virtualized environment, or install files explicitly and configure their paths as in section 2.6.

1.3 Build a small application with one intentional failure

For this exercise, use Delphi's VCL Forms Application project template, with a single main form. Save the project as FirstReport in a writable development folder and the form unit as MainForm.pas. Keep its generated class name TForm1. Place a TButton on the form and double-click it to create its OnClick handler. Ensure the form unit's uses clause includes System.SysUtils (use SysUtils on older Delphi versions without unit scopes).

Replace only the generated handler body with this complete handler:

procedure TForm1.Button1Click(Sender: TObject);
begin
  raise Exception.Create('FirstReport: deliberate test exception');
end;

The form designer supplies the class declaration and event connection. There is no intentional invalid pointer, division by zero, or damaged application state here: this is an ordinary Delphi exception raised by a main-thread VCL event. Do not put a try/except around this handler that silently consumes the exception.

Now enable instrumentation:

1. Save the project before opening Project > EurekaLog options.
2. Click Add EurekaLog to this project and choose the VCL Forms project type. A project-type profile selects the application integration; it is not the same thing as the IDE's Debug/Release build configuration.
3. For this local exercise, leave remote delivery unconfigured. On Bug report, enable Save bug report to file. Leave Bug report's location empty to use the per-user default, or choose a writable folder and a filename ending in .el.
4. Use Inject EurekaLog debug information and Store all names for this exercise, without a custom debug-information password. This avoids sidecar and password questions while proving basic operation.
5. Save the options. In ordinary Project > Options, confirm compiler Debug information and linker Map file = Detailed for the active configuration and platform. The expert normally sets these prerequisites, but you should know what the build depends on.
6. Select Project > Build or Build All, not just Compile/Make. Watch View > Messages, including the Build/Output pages where available, for the EurekaLog post-processing stage as well as compiler success.

EurekaLog needs both parts: units linked into the program provide the runtime code; post-processing adds the selected options and symbol information. Dropping TEurekaLogEvents on the form supplies neither a substitute for project setup nor a substitute for post-processing. That component is for callbacks after EurekaLog has been configured (chapter 9).

1.4 Read the result, not just the dialog

Run the newly built FirstReport.exe directly, outside the debugger, and press the button once. Running outside the IDE avoids confusing the debugger's first-chance exception notification with the application's final handling. The application should invoke its configured EurekaLog error dialog and write the local report.

Use Start > EurekaLog > Bug reports to open the current user's default report area, or open %APPDATA%\Neos Eureka S.r.l\Bug reports\ and its project subfolder. If you chose a custom path, look there first. A read-only custom directory can cause a fallback to the default. This is the account that runs the application, not necessarily the account that installed EurekaLog.

Open the .el report in a text editor or EurekaLog Viewer. Look for all of the following:

• The exception class Exception and the deliberate message you entered.
• The application/module identity and compilation information for the executable you just ran.
• A call-stack entry in MainForm, identifying TForm1.Button1Click and the source line containing raise.
• The time of this test, rather than an older entry: one local .el file may contain several reports.

There will also be framework and reporting frames. The useful result is a recognizable path into your application; it is not a promise that every frame in every external module has a source line. Chapter 11 explains stack reconstruction and symbol providers, and chapter 4 follows a report into the Viewer and source navigation.

If the test does not work, narrow the failure:

This exercise proves a main-thread VCL exception only. Worker threads require their own integration (chapters 15 and 21); DLLs/packages have lifetime and sharing rules (chapters 16 and 29). Do not extrapolate a button test into coverage of either.

1.5 Make the next test a release test

Before adding report delivery, repeat this exercise in the intended Release configuration and target platform, with a full rebuild. Section 2.2 explains why Release must retain the symbol inputs needed for field diagnostics. Keep the resulting report with the exact test binary and its build configuration as your baseline.

Remove the intentional exception handler and the test button/event connection before shipping, then rebuild again. The final application must not retain a user-accessible crash trigger. Removing that trigger also means the shipping binary is a new build: retain its own matching symbols, not only those of the test build.

Continue with chapter 2 to make the build reproducible, chapter 3 to configure and secure delivery, and chapter 4 to investigate the result. A successful first report establishes the reporting path; it does not establish that a transport works, that sensitive data is excluded, or that a production problem is solved.