Recently I stumbled into a situation where an unhandled exception gave me the choice to either kill Lazarus, or to continue at my own risk. Pressing the wrong shortcut key can be fatal in this situation :-( IMO such a dialog, with severe consequences, should not use standard OK/Cancel buttons, and also should not associate commonly used shortcuts with the buttons. Instead more intuitive Kill/Continue buttons should be used. In typical situations the Escape key is associated with Cancel, meaning to abort or undo a wrong action. In the case of an exception this should mean to cancel the *action* (and continue), not to kill the *application*.

On Wed, 14 Oct 2009, Hans-Peter Diettrich wrote: > Recently I stumbled into a situation where an unhandled exception > gave me the choice to either kill Lazarus, or to continue at my own > risk. Pressing the wrong shortcut key can be fatal in this > situation :-( > > IMO such a dialog, with severe consequences, should not use > standard OK/Cancel buttons, and also should not associate commonly > used shortcuts with the buttons. Instead more intuitive > Kill/Continue buttons should be used. > > In typical situations the Escape key is associated with Cancel, > meaning to abort or undo a wrong action. In the case of an > exception this should mean to cancel the *action* (and continue), > not to kill the *application*. I think that this is a good proposal. The QuestionDLG can be used for this, I assume.

On Thu, 15 Oct 2009 09:09:27 +0200 (CEST) Michael Van Canneyt wrote: > > > On Wed, 14 Oct 2009, Hans-Peter Diettrich wrote: > >> Recently I stumbled into a situation where an unhandled exception >> gave me the choice to either kill Lazarus, or to continue at my own >> risk. Pressing the wrong shortcut key can be fatal in this >> situation :-( >> >> IMO such a dialog, with severe consequences, should not use >> standard OK/Cancel buttons, and also should not associate commonly >> used shortcuts with the buttons. Instead more intuitive >> Kill/Continue buttons should be used. >> >> In typical situations the Escape key is associated with Cancel, >> meaning to abort or undo a wrong action. In the case of an >> exception this should mean to cancel the *action* (and continue), >> not to kill the *application*. > > I think that this is a good proposal. > The QuestionDLG can be used for this, I assume. The MessageBox is used, because it can be handled completely by the widgetset and therefore works even if the heap got corrupted. It is a matter of priority. Show some information to help fixing the bug, or help the user to ignore the bug.

We could: Add a flag to Application so that the programmer can decide what to show (MessageBox/QuestionDlg). And/Or: add an event to let the programmer show its own dialog.

On Thu, 15 Oct 2009, Mattias Gaertner wrote: > On Thu, 15 Oct 2009 09:09:27 +0200 (CEST) > Michael Van Canneyt wrote: > >> >> >> On Wed, 14 Oct 2009, Hans-Peter Diettrich wrote: >> >>> Recently I stumbled into a situation where an unhandled exception >>> gave me the choice to either kill Lazarus, or to continue at my >>> own risk. Pressing the wrong shortcut key can be fatal in this >>> situation :-( >>> >>> IMO such a dialog, with severe consequences, should not use >>> standard OK/Cancel buttons, and also should not associate commonly >>> used shortcuts with the buttons. Instead more intuitive >>> Kill/Continue buttons should be used. >>> >>> In typical situations the Escape key is associated with Cancel, >>> meaning to abort or undo a wrong action. In the case of an >>> exception this should mean to cancel the *action* (and continue), >>> not to kill the *application*. >> >> I think that this is a good proposal. >> The QuestionDLG can be used for this, I assume. > > The MessageBox is used, because it can be handled completely > by the widgetset and therefore works even if the heap got corrupted. > > It is a matter of priority. Show some information to help fixing the > bug, or help the user to ignore the bug. For a fact, the user usually cannot make this decision :-) > > We could: > Add a flag to Application so that the programmer can decide what to > show (MessageBox/QuestionDlg). > And/Or: add an event to let the programmer show its own dialog. This latter exists already, no ? OnShowException ?