MS Classic

This is setup options for MS Classic dialog (edtMSClassic). They are located at Dialogs tab.

MS Classic dialog options

Note: error messages in dialogs are controlled by nested exceptions behaviour options.

1. "Ask user for send consent" (.edoShowSendErrorReportOption) option will ask user for their consent before sending bug report to developer - by showing "Please tell us about the problem" and presenting "Send Error Report" and "Don't send" buttons.

This option has no effect if you haven't specified any sending methods. In this case you'll see only one "OK" button. For example:

Asking for consent is unchecked or there is no sending method available

Asking for consent is checked and sending method present

Important: be aware that sending user's data without a consent violates GDPR. Violators of GDPR may be fined up to €20 million, or up to 4% of the annual worldwide turnover of the preceding financial year, whichever is greater. We recommend to seek advice from GDPR consulting company before disabling consent. See also: Security Considerations.

2. Default choice is selected by enabling/disabling "Default choice: send report" (.edoSendErrorReportChecked) option. If this option is checked - the default choice is to send the report. If this option is unchecked - then the default choice is NOT to send the report. Default choice affects which button (option) will be highlighted/selected when dialog is shown.

3. "Show 'click here' link" (.edoShowDetailsButton) option adds a "To see what data the error report contains, click here." line to the dialog. A "click here" part is a hyper-link which opens a EurekaLog style dialog in "detailed" mode. For example:

"Show 'click here' link" option is unchecked

"Show 'click here' link" option is checked

4. "Ask user for steps to reproduce" (.loAppendReproduceText) option shows a memo with "What were you doing when the problem happened (optional)?" header. For example:

"Ask user for steps to reproduce" option is unchecked

"Ask user for steps to reproduce" option is checked

5. "Show e-mail control" (.edoShowEMailControl) option shows the edit for user's e-mail address. You can get/set this e-mail manually by using GetUserEMail and SetUserEmail functions. For example:

"Show e-mail control" option is unchecked

"Show e-mail control" option is checked

6. "Mandatory e-mail" (.edoMandatoryEMail) option will not allow user to close dialog without entering a proper e-mail. This option have no effect if e-mail input control is not visible. Use this option to force user to specify e-mail. This options is useful if you perform delayed/queued report sending manually. For example, you store your bug report in folder, then some application pick up/send/process this folder - and you want bug reports to have end user e-mail for contacting it.

7. "Only when sending" (.edoMandatoryEMailOnlyWhenSending) option modifies mandatory e-mail option. When this option is disabled - e-mail will always be required. When this option is enabled - e-mail will be optional if user closes dialog without sending report. Use this option if you want user e-mail specified, and you perform sending immediately (via EurekaLog).

8. "Show a custom 'Help' button" (.edoShowCustomButton) option shows a "Help" button in the left-bottom corner of the dialog. You can assign your code on this button via the OnCustomButtonClick event.

"Show a custom 'Help' button" option is unchecked

"Show a custom 'Help' button" option is checked

Note: while the proposed usage for this button is to act as "Help on this error" button, but you can freely implement any other behavior. You can implement arbitrary behavior by assigning OnCustomButtonClick event, and you can change caption of this button by either altering localization options at design-time or assigning a new value to CurrentEurekaLogOptions.CustomizedTexts[mtDialog_CustomButtonCaption].

9. "Replace 'Application' with real application name" (.edoUseRealName) option will replace "application" word in all messages on the error dialog with FileDescripton field from version information of main executable (not from module where exception has occurred) - so called "real application name" (in this article). The usual places for such replacements include:

If there is no version information available or FileDescription field is empty - then this option will have no effect and you'll see the standard "application" instead of description.

In the example below: the FileDescription field of main .exe contains 'Sample Application' string.

"Replace 'application' with real application name" option is unchecked

"Replace 'application' with real application name" option is checked

Usually this option is used together with "Replace error icon with real application icon" option (see below) to get a fully personalized view.

10. "Replace error icon with real application icon" (.edoUseRealIcon) option will replace standard IDI_ERROR icon to icon of the main .exe (i.e. the first icon). For example:

"Replace error icon with real application icon" option is unchecked

"Replace error icon with real application icon" option is checked

Usually this option is used together with "Replace 'application' with real application name" option (see above) to get a fully personalized view.

11. "Modal window" (.edoShowModal) option makes error dialog modal. Modal means that only error dialog will be accessible. All other windows in current thread will be disabled (user will not be able to interact with them). Windows from other processes and from other threads within the same process will be accessible. When this option is unchecked - no other windows will be disabled.

Note: usually it's not good idea to uncheck "Owner window" option when "Modal window" option is checked.

12. "Owner window" (.edoOwnedWindow) option makes error dialog an owned window to currently active window (owner window). Here: Owner-Owned relation is used in system's meaning (as relation between two HWND) as opposed to Delphi's meaning (as relation between two TComponent).

Checked: error dialog will be displayed as owned window to currently active window. If there is no active window - this option will have no effect. Being owned places several constraints on a window. Generally, owner-owned windows act as group. For example, an owned window is always above its owner in the z-order. Both owner and owned windows "share" the same button on taskbar (actually, owned window do not have taskbar button). An owned window is hidden when its owner is minimized.

Unchecked: error dialog will not be related to any other window. It will be standalone window.

Note: usually it's not good idea to uncheck "Owner window" option when "Modal window" option is checked.

13. "Right-To-Left" option enables Right-To-Left layout. This is global option that affects all EurekaLog run-time dialogs. Unchecked position indicate left-to-right layout (default), checked position indicate right-to-left layout used in some middle eastern languages. This option can also be altered at design-time via Localization page. This option can also be altered at run-time by changing CurrentEurekaLogOptions.CustomizedTexts[mtRTLDialog].

14. "Show dialog in Top-Most state" (.edoShowInTopMostMode) option sets the HWND_TOPMOST position to error dialog. If this option is checked then error window will appear above all other non-TopMost windows. If this option is unchecked then HWND_TOPMOST will not be set. Instead, a timer is run. This timer will call SetForegroundWindow for error dialog, if it was covered by any other process's windows. Windows from other processes can cover error window. Windows from current process, which are created after error dialog can cover error dialog too. The timer will fire only few times to avoid 2+ windows fighting over top place. This timer doesn't work in TopMost mode.

15. "Do nothing" / "Show 'Restart' checkbox" / "Show 'Terminate' checkbox" after N errors (.TerminateBtnOperation, .ErrorsNumberToShowTerminateBtn, .edoRestartChecked) option controls the visibility of "restart" and "terminate" checkboxes:

"Do nothing" option is selected or error count is less than the specified count.

"Show 'Terminate' checkbox" options is selected and error count is more than the specified count.

The "Checked" option controls if this checkbox is initially checked or unchecked. If "Checked" option is checked, then when MS Classic dialog appears with restart/terminate checkbox visible - this checkbox will be checked. And the opposite: if the "Checked" option is not checked, then restart/terminate checkbox will be unchecked, when dialog appears. Of course, this option have no effect, if checkbox is not visible (for example, if you select "Do nothing" option).

A "after N errors" part is controls, when to show restart/terminate checkbox. Again, this part is ignored, if you select "Do nothing" option. Value of 0 means that restart/terminate checkbox will be visible always. Value of 1 means that checkbox will be displayed only in second error dialog. Value of 2 means that you got two error dialog without checkbox and 3rd dialog will have it. And so on.

At run-time: when user checks restart/terminate checkbox, then your application will be restarted or terminated after closing error dialog and saving and sending bug report (if enabled). If user unchecks the checkbox - then your application will continue to run.

Note:

16. "Close every exception dialog after M seconds" (.AutoCloseDialogSecs) option allows you to automatically close exception dialogs after timeout of inactivity. Value of 0 means disabling of such feature - i.e. each dialog may be closed only manually by user (via clicking on dialog's buttons). Any other value (> 0) means that dialog will be closed after that amount of seconds, passed since its popup. For example, if you specify 180 seconds - then dialog will be closed exactly after 3 minutes, if user didn't closed it before.

This option is useful to auto-close error dialogs in possible non-interactive scenarios. Note, that it may be preferable to select other dialog type (non-GUI) in such cases.

Note: this option specifies the delay of user's inactivity. If user moves mouse, presses buttons or generates any other input in dialog - auto-close timer will reset. Therefore, setting this option to, say, 5 seconds does not mean that dialog will be closed after 5 seconds. It may stay for, say, 1 minute - but only if user is working with it. Dialog will be closed after 5 seconds if user is away (not moving mouse, etc.).

See also: