On 27/04/12 17:20, Bart wrote:
On 4/27/12, patspiper<[email protected]> 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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
