[Lazarus] Inconsistent results from MessageDlg()

[patspiper]

On 27/04/12 17:20, Bart wrote:
> On 4/27/12, patspiper<patspiper at gmail.com>  wrote:
>
>
>> To summarize, your target is:
> [snip]
>> c- TBitButton with Kind=bkClose and ModalResult=mrNone: Close form and
>> set its ModalResult to mrCancel.
> Yes (but not 100% accurate)
I was referring to the end result, not the mechanism.
>> - 1a and 1b are intuitive whereas 1c is not, irrespective of the
>> different Delphi versions implementations. If one wants to close the
>> form and return mrCancel, he should set the BitButton's ModalResult to
>> mrCancel. The TBitBtn with bkClose and mrNone will only Close the ParentForm.
> It does not set ModalResult.
> TCustomForm.ShowModal will eventually set ModalResult := mrCancel if
> ModalResult = mrNone
Same comment as above.
>> I can't see why he would set it as mrNone and expect it to act
>> as mrCancel
> This is Delphi legacy.
> Originally bkClose was introduced, but no mrClose existed.
> By default TBitBtn with bkClose had mrClose as ModalResult.
> As the "Kind" suggest it closes the ParentForm (always).
> Eventually this will mean that ParentForm.ModalResult will be mrCancel.
>
> Delphi still acts this way AFAIK.
Lazarus doesn't have to bear Delphi's legacy shortcomings, especially in 
such a minor issue. I prefer that mrClose, mrCancel, and mrNone each do 
what they imply they do.
>
>> 3- LCL's CreateMessageDialog():
>>
>> a- [x] closes the dialog and return mrCancel
>>
>> b- Escape closes the dialog and returns mrCancel, mrNo, or mrOK if and
>> only if one of mbCancel, mbNo, and mbOk is present repectively and in
>> that order of precedence. Otherwise, Escape key does not have any effect.
> This is how my patch works, yes.
>
>> - 3a is logical and is in accordance with 2a
>>
>> - 3b deviates from 2a (I would assume native and LCL's dialogs should
>> behave the same).
> And again, this exactly how Delphi does it.
> Native Vista (and up) dialogs return mrCancel on Escape, XP and lower
> will only close the dialog if mbCancel, mbNo or mbOk is in Buttons,
> and it will return the ModalResult of the button in question.
>
>
> Ultimately there are 3 choices:
>
> 1. Make it Delphi compatible (current implementation is not), accept
> some inconsistencies (for which programmer must check anyway) between
> native and LCL.
> 2. Make LCL behave like native Windows
> 3. Don't bother at all.
>
> I choose option 1 (I am the one who's actively working on it, hardly
> anyone else seems to care).
> If we (Lazarus community) decide option 2 is better, I'll code that
> (it is actually easier to achieve than option 1).
Should Lazarus apps behave differently on different platforms (Windows 
and Linux flavours) unless OS related IFDEF's are put in place? Or 
should they be consistent on all platforms? That's one factor to consider.

Another factor is: Should the native and LCL dialogs both behave the 
same or not?

Once these 2 questions are answered, it will be much easier to make an 
informed decision.

> Since I care, option 3 is not an option for me ;-)
;-)

Stephano