patspiper schrieb:
On 22/04/12 16:06, Bart wrote:
On 4/22/12, patspiper<[email protected]> wrote:
But I have a slightly different suggestion:
2- Escape key should first check if any button has Cancel=true, and use
that button's modal result. Otherwise, mrCancel is in order as the user
is running away from answering the dialog.
AFAIK, no Button has Escape = True (maybe except for mbCancel) in
TPromptDialog.CreateMessageDialog.
IIRC you mentioned that possibility in your OP. If no button has
Cancel=true then there are 2 options:
- Escape key returns mrCancel
- Escape key has no effect unless mbCancel button is there
- Escape key has no effect whatsoever.
3- [x] should either return mrCancel, or mimic the Escape key. The
latter is the more logical choice, as the programmer has intentionally
defined the action (by setting a button's Cancel to true) if the user
wants to run away.
Not the case, as stated above.
User (as in application programmer) has no influence over this for
MessageDlg.
Options for [x]:
- Suppress it (don't show it)
- Mimic Escape key
- return mrCancel
IMO we should consider the real control flow. When a button with a
ModalResult<>mrNone is clicked, the modal form should close and return
this value. Here the VCL is flawed, because it closes the form when a
button with Kind=bkClose is clicked, *without* returning the assigned
(or an implied) button.ModalResult.
When a modal form can be closed by other means, because an OS or
widgetset does allow this, then also a defined ModalResult should be
returned - maybe mrNone or mrCancel (to be defined). Eventually the
default ModalResult could be assigned by the caller, *prior* to calling
ShowModal.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
