[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