[Lazarus] Inconsistent result from MessageDlg
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Sat Aug 20 11:54:14 CEST 2011
Hans-Peter Diettrich schrieb:
> Bart schrieb:
>> On 8/19/11, Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:
>>> Bart schrieb:
>>>
>>> IMO it's perfectly sufficient to also map Close to the Cancel button,
>>> and to disallow Close when no button has Cancel=True.
>>
>> ?
>>
>> You won't be able to do this when using TaskDialogIndirect(), it's
>> just a Windows modal dialog form, and clicking on the "Close"
>> border-icon will close it no matter what we think is convenient...
No TaskDialogIndirect procedure in XE. MessageDlgPosHelp forks:
if (Win32MajorVersion >= 6) and UseLatestCommonDialogs and
ThemeServices.ThemesEnabled then
Result := DoTaskMessageDlgPosHelp('', Msg, DlgType, Buttons,
HelpCtx, X, Y, HelpFileName)
else
Result := DoMessageDlgPosHelp(CreateMessageDialog(Msg, DlgType,
Buttons),
HelpCtx, X, Y, HelpFileName);
where the first version creates an TTaskMessageDialog
(TCustomTaskDialog), the latter a TForm.
>> Also there is the Delphi compatibility issue (cannot test that, my
>> Delphi is much to old).
>
> I'll test with Delphi XE...
The Delphi documentation is outdated, as usual. Experiments on XP
suggest that the dialog Close (X) returns mrCancel(=IDCANCEL),
regardless of the specified buttons.
TCustomTaskDialog.Flags:TTaskDialogFlags include
tfAllowDialogCancellation, which seems to be ON by default, and
tfCanBeMinimized. These flags look as being related to the window menu.
ESC does nothing or maps to e.g. mrNo, depending on the specified buttons.
IMO we are free to return whatsoever when the dialog is only closed, or
deny close, as "compiler specific" (undefined) behaviour. I still think
that only one of the specified buttons should be returned as the result,
so that a Close should act like ESC.
DoDi
More information about the Lazarus
mailing list