A report is where the investigation starts
Your program has failed on a machine you cannot sit in front of. The user remembers clicking a button. The debugger was nowhere near it. What would you like to have kept?
That is the job EurekaLog does: preserve enough of the failure to give you a useful next move. This book is about making that move possible. First get a small application to produce a report you can trust. Then get that report into the right hands. Only then reach for the hooks, custom classes and low-level machinery.
You do not need to read this book from cover to cover before writing code. Nor do you need to work through an online tree of options to follow its procedures. The practical path is at the front; the explanations and contracts are here when you need to go deeper.
Pick the door that matches your problem
| What you want to do | Start here |
|---|---|
| Install EurekaLog, enable a project and see a first useful report | chapter 1 |
| Make Debug, Release, C++Builder and command-line builds behave consistently | chapter 2 |
| Save or deliver reports without exposing credentials or unnecessary user data | chapter 3 |
| Open a report, find the matching code and decide what to investigate | chapter 4, then chapter 20 |
| Find out why there is no report, why a build behaves differently, or where the overhead comes from | chapter 5 |
| Call EurekaLog from your own code | chapter 6 |
| Add context or change exception processing | chapter 7, then chapter 24 |
| Work with threads, DLLs or leak detection | chapters 21, 16 and 22 |
| Recognize a misleading report without guessing its cause | chapters 26, 27, 28 and 29 |
| Look up a routine, type, unit or class whose name you already know | appendices A, B, C and D |
If you are new to EurekaLog, follow the first five chapters as a short working journey. Use a small throwaway project, not the application you are about to ship. A deliberate exception is a better first experiment than waiting for a genuine customer failure.
If EurekaLog is already in your application, start with the question you have today. The unit chapters are reference with explanation, not prerequisites for the practical chapters. The appendices are for lookup, not a reading assignment.
How the book is arranged
- Part I - Get a useful report, then make it dependable. Installation, builds, delivery, investigation and troubleshooting, in the order a working integration needs them.
- Part II - Working with EurekaLog from code. State, exceptions, callbacks and the manager behind them.
- Part III - The units you actually use. The contracts and the reasons behind them: stacks, memory, logging, threads, DLLs, settings and low-level helpers.
- Part IV - Diagnose and customize. Reading evidence and applying the API to whole problems rather than isolated calls.
- Part V - Cases that teach a useful distinction. Real failure patterns, with their conditions and the point at which the evidence stops.
- Appendices - Look it up without leaving the book. Available API declarations, parameters, results, ownership rules and limitations, organized for consultation.
Three things worth keeping separate
Installed is not active. A project can contain EurekaLog while reporting is disabled, or while a particular thread is outside the reporting path. The first question is not always "which handler is broken?" It may be "did this build and this thread ever enter the path?"
Detection is not explanation. A stack shows where something was observed. A leak check shows what was still allocated when it ran. A freeze detector tests a particular kind of responsiveness. Each is useful; none is a substitute for understanding its boundary.
A documented contract is not a successful retest. The API chapters describe the available vendor contracts. The cases distinguish what a customer saw, what support proposed, what was reproduced and what was actually reported working. A released fix is not automatically a tested fix for your application, and a workaround is not a new rule for every version.
Those distinctions appear throughout the book because they prevent expensive mistakes, not because you need to memorize a vocabulary before getting started.
Versions and examples
This book covers EurekaLog 7 for Delphi and C++Builder. Check the product build, compiler, platform and project type before applying a version-specific restriction or historical fix. An implementation note labelled 7.15.0.0 applies to that build; it is not a compatibility promise for every EurekaLog 7 release.
API declarations use Delphi syntax. C++Builder uses the corresponding generated headers; its setup and memory-management requirements have their own path in chapter 2. Do not translate a calling convention or ownership rule by intuition.
Examples identify the context they need. A handler body, a unit initialization fragment and a complete program are different things. Apply a change in a controlled build, check the report it produces, and remove deliberate test failures before deployment. Where an API has no documented guarantee, do not rely on an inferred one.
The case studies describe particular product versions, compiler generations, platforms and outcomes. Match those conditions before borrowing a remedy; a successful retest in one application does not establish that every similar symptom has the same cause.