Root > How to... > ...change EurekaLog's settings at run-time? > ...use different settings for development/production?

...use different settings for development/production?

Previous pageReturn to chapter overviewNext page   

A common usage case is have some features of EurekaLog disabled for production. For example, if you are using EurekaLog during development - you probably want memory checks enabled, as well as show detailed exception dialog with call stack by default. However, when compiling a production build - you probably want more user-friendly exception dialog and/or disabled memory checks/leaks.


This article will discuss the case when you want to have EurekaLog enabled in both Debug and Release build configurations, but with different settings. If you want EurekaLog to be enabled for Debug build configuration and be disabled for Release build configuration (or visa versa) - please, see How to enable EurekaLog for production, disable for development article instead.


Important Note: some features of EurekaLog can be automatically disabled if no debugger is present. For example, memory leaks and freeze/hang/deadlock detection. Therefore, if you are only interested in those features - you may not need to do anything at all. Just configure the features.



How to differentiate between development and production builds

Default project configuration in modern IDEs has 3 build configurations defined:

Base build configuration
Debug build configuration
Release build configuration

The supposed meaning is using Debug build configuration for developing and using Release build configuration for production.



Default build configurations


You can also check current build configuration in your source code:


ShowMessage('Development build');
ShowMessage('Production build');


We recommend to follow that approach.


Important: you are supposed to configure Release build configuration for EurekaLog.


Note: if you are using old IDE without build configurations support - the alternative way would be to create two projects, which will include the same set of units and share the same project source (.dpr file). Assign one project to be a development project, and second project to be a production project. The example below would use modern IDE as an example.


Important: do not forget to make a full project rebuild (not just compile) when you have switched active build configuration.



How to use different EurekaLog settings for production (run-time)

If you want to disable certain features of EurekaLog for production - you may easily do it in your source code without need to create an alternative settings. For example:


  EMemLeaks,     // for ActivateMemoryLeakCheck
  EModules,      // for CurrentEurekaLogOptions
  EFreeze,       // for CurrentEurekaLogOptions
  ETypes,        // for constants
  ExceptionLog7; // to initialize EurekaLog before our customizations
  // Development build
  // Do not save local bug report
  CurrentEurekaLogOptions.SaveLogFile := False;
  // Do not send bug report
  CurrentEurekaLogOptions.SenderClasses := wsmNoSend;
  // Show details immediately
  CurrentEurekaLogOptions.ExceptionDialogType := edtEurekaLogDetailed;

  // Disable hangs detection

  // Production build
  // User-friendly dialog
  CurrentEurekaLogOptions.ExceptionDialogType := edtMSClassic;
  // Disable all memory checks


This example assumes that EurekaLog's project settings contains common settings for both build configurations. For example, send settings are set up, hang detection is enabled, memory checks are enabled, etc.


Such approach may be not ideal. For example, it would be better if memory checks are disabled from the start, as disabling checks at run-time would not remove EurekaLog's memory filter shim. Or there may be a lot of settings that you want to be different. Or it may be easier for you to manage settings via UI.


Important: do not forget to make a full project rebuild (not just compile) when you have switched active build configuration.



How to use different EurekaLog settings for production (design-time)

Anyway, you can create alternative settings, which should be used for your production builds. That way you don't need to write any code.


1. Go to Project / EurekaLog options;
2. Configure EurekaLog for production build. E.g. disable memory checks, enable hang detection, etc.;
3. Click on the "Export" button;
4. Save settings as Project1_Release.eof file in the same folder as your project (replace "Project1" with your real project name).
5. Configure EurekaLog for development build. E.g. enable memory checks, disable hang detection, etc.;
6. Save settings by pressing the "OK" button.


Now you should have the following in your project's folder:

Project1.dpr - your project;
Project1.eof - base settings for EurekaLog for all build configurations - including development builds;
Project1_Release.eof - EurekaLog settings for production (e.g. Release build configuration).


Now you can compile your project:

When you are compiling your project with Release build configuration active - EurekaLog will use your production settings from the Project1_Release.eof file;
When you are compiling your project with Debug build configuration active - EurekaLog will use your base/development settings from the Project1.eof file;


Important: do not forget to make a full project rebuild (not just compile) when you have switched active build configuration.


If you want to learn more details - see Different EurekaLog settings for Debug and Release build configurations.



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2022-02-02
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: