Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-04

Inconsistent results from MessageDlg()

37 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bart

Hi all,

MessageDlg eventually calls WidgetSet.PromptUser() This in return either calls and sets up a widgetset specific function (like TaskDialogIndirect on Windows Vista/Win7) or if such an implementations does not exist it calls
TPromptDialog.CreateMessageDialog() and the LCL will build it's own MessageDialog form with appropriate buttons etc.

I see 3 problems (see http://bugs.freepascal.org/view.php?id=21801 ).

1.

If the TPromptDialog.CreateMessageDialog is called then if mbClose is specified in Buttons, clicking on mbClose will not return mrClose but mrCancel (which is incompatible with Delphi).
This is because a TBitBtn with Kind = bkClose will not set ModalResult for it's parentform, it will only close the parentform, thus ultimately Modalresult will be mrCancel.

This can be fixed in TPromptDialog (see patch in bugtracker) or the behaviour of TBitBtn could be altered?
(Can somebody check how Delphi responds to a TBitBtn with Kind=bkClose and ModalResult=mrClose?)

2.

If the user clicks on the X-bordericon to close the dialog, then Result should be mrCancel (the Delphi way), but currently the result depends on the widgetset.
If there is a specific widgetset implementation It either returns mrCancel, or it returns the result of ModalEscapeValue(Buttons). If there is no specific widgetset implementation and TPromptDialog.PromptUser is called, it returns mrCancel.

3.

If the user presses the Escape key (on keyboard) results will be either mrCancel or ModalEscapeValue(Buttons) depending on the widgetset.

I would like to discuss how MessageDlg should behave when the user closes the dialog by clicking the X-bordericon or pressing the Escape key.

My opinions:

How to handle clicking on X-border-icon?

To be Delphi compatible clicking on the X-bordericon should always return mrCancel as result IMHO.
(A patch for the win32 widgetset is attached to the above mentioned bugreport)

How to handle the EscapeKey?

Older Delphi's seem to return a value depending on the Buttons available, much like ModalEscapeValue() does. In my Delphi (3) the dialog does not always close if you press the Escape key. It looks like it only handles Escape if one of the Buttons has Cancel = True. For instance specifying [mbAbort, mbRetry, mbIgnore] will not respond to pressing Escape on modern Delphi (XE) presssing escape key will return mrCancel (because the Windows dialog will return IDCANCEL).

Maybe it is a matter of taste.
I would propose to always return mrCancel, since it reflects the users action better then guessing what the user intended. This should not break current programs, since mrCancel can always be returned by any MessageDlg with any combination of buttons, and it should be dealt with.
Also the newer Delphi's seem to go in this direction.

OTOH to remain compatibility with "older" Delphi's, we could still return ModalEscapeValue().
On Vista and up however, we cannot distinguish between pressing Escape-key and clicking X-border icon anymore, so we probably only should do this in TPromptDialog.

In the case of returning ModalEscapevalue() I would like to add in ModalEscapeValue() the possibility to return mrClose.

Bart

Reply by email

zeljko
to Bart
Bart wrote 12 lines
Hi all, MessageDlg eventually calls WidgetSet.PromptUser() This in return either calls and sets up a widgetset specific function (like TaskDialogIndirect on Windows Vista/Win7) or if such an implementations does not exist it calls TPromptDialog.CreateMessageDialog() and the LCL will build it's own MessageDialog form with appropriate buttons etc. I see 3 problems (see http://bugs.freepascal.org/view.php?id=21801 ). 1.
How to handle clicking on X-border-icon?

afair, qt and gtk2 have default result for that and escape key (you can set on dialog what is the value of default result for [X] and escape), result should be mrCancel in any case.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120422/0f73e8aa/attachment.html>

Reply by email

patspiper
to zeljko
zeljko wrote 36 lines
On Sunday 22 of April 2012 12:28:43 Bart wrote: > Hi all, > > MessageDlg eventually calls WidgetSet.PromptUser() > This in return either calls and sets up a widgetset specific function > (like TaskDialogIndirect on Windows Vista/Win7) or if such an > implementations does not exist it calls > TPromptDialog.CreateMessageDialog() and the LCL will build it's own > MessageDialog form with appropriate buttons etc. > > I see 3 problems (see http://bugs.freepascal.org/view.php?id=21801 ). > > 1. > How to handle clicking on X-border-icon? afair, qt and gtk2 have default result for that and escape key (you can set on dialog what is the value of default result for [X] and escape), result should be mrCancel in any case.

+1

The current result for Escape and [x] (at least under GTK2) is mrOK which is very misleading.

But I have a slightly different suggestion:

1- This should apply to any modal form, not only MessageDlg and WidgetSet.PromptUser.

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.

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.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120422/4f563c26/attachment-0001.html>

Reply by email

zeljko
to patspiper
patspiper wrote 38 lines
On 22/04/12 14:09, zeljko wrote: > On Sunday 22 of April 2012 12:28:43 Bart wrote: > > Hi all, > > > > > > > > MessageDlg eventually calls WidgetSet.PromptUser() > > > > This in return either calls and sets up a widgetset specific function > > > > (like TaskDialogIndirect on Windows Vista/Win7) or if such an > > > > implementations does not exist it calls > > > > TPromptDialog.CreateMessageDialog() and the LCL will build it's own > > > > MessageDialog form with appropriate buttons etc. > > > > > > > > I see 3 problems (see http://bugs.freepascal.org/view.php?id=21801 ). > > > > > > > > 1. > > > > > > > > How to handle clicking on X-border-icon? > > afair, qt and gtk2 have default result for that and escape key (you > can set on dialog what is the value of default result for [X] and > escape), result should be mrCancel in any case. +1 The current result for Escape and [x] (at least under GTK2) is mrOK which is very misleading.

Maybe in case when there's only one button (mbOK). Have you tested with eg. mbYes,mbNo or others ?
Also , maybe I didn't spotted that in my applications since i never evaluate
1. if there's only one button (so thats dialog with information or error, I don't care how user closed that dlg)
2.anything except mrResult which should continue (usually mrYes or mrOk). eg. if MessageDlg(blabla) mrYes then

  exit;

zeljko

Show quoted text 16 lines
But I have a slightly different suggestion: 1- This should apply to any modal form, not only MessageDlg and WidgetSet.PromptUser. 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. 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. Stephano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120422/b24c449d/attachment.html>

Reply by email

patspiper
to zeljko
zeljko wrote 85 lines
On Sunday 22 of April 2012 13:35:59 patspiper wrote: > On 22/04/12 14:09, zeljko wrote: > > On Sunday 22 of April 2012 12:28:43 Bart wrote: > > > Hi all, > > > > > > > > > > > > MessageDlg eventually calls WidgetSet.PromptUser() > > > > > > This in return either calls and sets up a widgetset specific function > > > > > > (like TaskDialogIndirect on Windows Vista/Win7) or if such an > > > > > > implementations does not exist it calls > > > > > > TPromptDialog.CreateMessageDialog() and the LCL will build it's own > > > > > > MessageDialog form with appropriate buttons etc. > > > > > > > > > > > > I see 3 problems (see http://bugs.freepascal.org/view.php?id=21801 ). > > > > > > > > > > > > 1. > > > > > > > > > > > > How to handle clicking on X-border-icon? > > > > afair, qt and gtk2 have default result for that and escape key (you > > can set on dialog what is the value of default result for [X] and > > escape), result should be mrCancel in any case. > > +1 > > The current result for Escape and [x] (at least under GTK2) is mrOK > which is very misleading. Maybe in case when there's only one button (mbOK). Have you tested with eg. mbYes,mbNo or others ?

You are partially right on this. I tested all the buttons with MessageDlg and this is the order of precedence from high to low: mrOK
mrCancel
mrNo
mrAbort
mrIgnore
mrNoToAll
mrYes
mrRetry
mrAll
mrYesToAll

if mbClose is the only button, the modal result is mrCancel.

Also , maybe I didn't spotted that in my applications since i never evaluate 1.

Pls disregard my point #1. It is not very logical.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120422/af818907/attachment.html>

Reply by email

patspiper
to cobines
cobines wrote 6 lines
2012/4/22 patspiper: > 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. That's different because currently Escape does not close a modal form unless there's a button with Cancel=true.

For other modal forms: True, and I mentioned that in 2 follow-up emails.

For the MessageDlg and WidgetSet.PromptUser, the Escape key closes the dialog.

Stephano

Reply by email

Bart
to patspiper: +1 The current result for Escape and [x] (at least under GTK2) is mrOK which is very…
patspiper wrote 5 lines
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.

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.

Bart

Reply by email

patspiper
to Bart
Bart wrote 7 lines
On 4/22/12, patspiper 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.

Show quoted text 7 lines
> 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

Stephano

Reply by email

Hans-Peter Diettrich
to patspiper: IIRC you mentioned that possibility in your OP. If no button has Cancel=true then there…
Show quoted text 25 lines
On 22/04/12 16:06, Bart wrote: > On 4/22/12, patspiper 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 ModalResultmrNone 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

Reply by email

Bart
to Bart: is run in XP. Bart
Bart wrote 11 lines
On 4/22/12, Bart wrote: > In my Delphi (3) the > dialog does not always close if you press the Escape key. It looks > like it only handles Escape if one of the Buttons has Cancel = True. > For instance specifying [mbAbort, mbRetry, mbIgnore] will not respond > to pressing Escape key at all. This in effect is stil the case in Delphi XE when the compiled program is run in XP. Bart

Delphi infact only responds to escape if either mbCancel, mbNo or mbOk is in Buttons and it assigns Cancel to those buttons in that order.

Bart

Reply by email

Bart
to Bart: MessageDlg eventually calls WidgetSet.PromptUser() This in return either calls and sets…

Hi,

I have created a patch which behaves like this:
(see: http://bugs.freepascal.org/view.php?id=21801#attachments , file: msgdlg.diff)

If the widgetset has a (native) PromptUser function, then the behaviour of the dialog is as follows:
- Escape and [X]-bordericon will return mrCancel

If no widgetset specific PromptDialog is set up, then eventually TPromptDialog.CreateMessageDialog() is called.
I have changed it's behaviour to be compatible with Delphi:
- [X]-bordericon will return mrCancel
- Escape will only close the dialog if mbOk, mbNo or mbCancel is in Buttons, in this case it will return mrCancel, mrNo or mrOk (in that order) It does so by setting the Cancel property of the appropriate Button (as long as TBitBtn.Cancel works across widgetsets, this should work, but I can only test this on windows myself)

This behaviour is consistent with both older Delphi's and newer ones using the new Vista-dialogs (as does Lazarus).

To properly resond to mbClose, the proposed patch from http://bugs.freepascal.org/view.php?id=0021844 should also be applied.

Can one of the Lazarus devels take a look at my proposed patch and apply or give feedback?

Bart

Reply by email

patspiper
to Bart
Bart wrote 20 lines
Hi, I have created a patch which behaves like this: (see: http://bugs.freepascal.org/view.php?id=21801#attachments , file: msgdlg.diff) If the widgetset has a (native) PromptUser function, then the behaviour of the dialog is as follows: - Escape and [X]-bordericon will return mrCancel If no widgetset specific PromptDialog is set up, then eventually TPromptDialog.CreateMessageDialog() is called. I have changed it's behaviour to be compatible with Delphi: - [X]-bordericon will return mrCancel - Escape will only close the dialog if mbOk, mbNo or mbCancel is in Buttons, in this case it will return mrCancel, mrNo or mrOk (in that order) It does so by setting the Cancel property of the appropriate Button (as long as TBitBtn.Cancel works across widgetsets, this should work, but I can only test this on windows myself)

I suggest TPromptDialog.CreateMessageDialog() behave the same as the widgetset's PromptDialog (both Escape and [X]-bordericon return mrCancel). That would be more consistent.

Show quoted text 5 lines
This behaviour is consistent with both older Delphi's and newer ones using the new Vista-dialogs (as does Lazarus). To properly resond to mbClose, the proposed patch from http://bugs.freepascal.org/view.php?id=0021844 should also be applied.

As for TBitBtn, I suggest Lazarus respects the button's modalresult and acts accordingly.

Stephano

Reply by email

Bart
to patspiper
patspiper wrote
As for TBitBtn, I suggest Lazarus respects the button's modalresult and acts accordingly.

By default a Button with ModalResult = mrNone will not close it's parentform when clicked.
A TBitBtn with Kind = bkClose and ModalResult is the exception to this rule. It should close the parentform, not setting it's ModalResult (which will result in ModalResult of parentform being mrCancel).

A TBitBtn with ModalResult mrNone should always set parentform's ModalResult (regardless of Kind), which is what my patch does.

Bart

Reply by email

Mattias Gaertner
to Bart: I have created a patch which behaves like this: (see:…
Show quoted text 30 lines
Hi, I have created a patch which behaves like this: (see: http://bugs.freepascal.org/view.php?id=21801#attachments , file: msgdlg.diff) If the widgetset has a (native) PromptUser function, then the behaviour of the dialog is as follows: - Escape and [X]-bordericon will return mrCancel If no widgetset specific PromptDialog is set up, then eventually TPromptDialog.CreateMessageDialog() is called. I have changed it's behaviour to be compatible with Delphi: - [X]-bordericon will return mrCancel - Escape will only close the dialog if mbOk, mbNo or mbCancel is in Buttons, in this case it will return mrCancel, mrNo or mrOk (in that order) It does so by setting the Cancel property of the appropriate Button (as long as TBitBtn.Cancel works across widgetsets, this should work, but I can only test this on windows myself) This behaviour is consistent with both older Delphi's and newer ones using the new Vista-dialogs (as does Lazarus). To properly resond to mbClose, the proposed patch from http://bugs.freepascal.org/view.php?id=0021844 should also be applied. Can one of the Lazarus devels take a look at my proposed patch and apply or give feedback?

Can you update the fpdocs too for MessageDlg?

Mattias

Reply by email

Mattias Gaertner
to Bart
Show quoted text 6 lines
On 4/26/12, Mattias Gaertner wrote: > Can you update the fpdocs too for MessageDlg? > You mean the description in ($lazarus)\docs\xml\lcl\dialogs.xml ?

Yes. Although it is easier use the fpdoc editor and forget about file names.

If so, I can do that and attach it as a separate diff to the bugreport.

Thanks.

Mattias

Reply by email

Bart
to Mattias Gaertner
Mattias Gaertner wrote
> You mean the description in ($lazarus)\docs\xml\lcl\dialogs.xml ? Yes. Although it is easier use the fpdoc editor and forget about file names.

I never got the hang of fpdoc, so I manually edited the xml. I attached diff to the bugreport in question.
Please review.

Bart

Reply by email

patspiper
to Bart: By default a Button with ModalResult = mrNone will not close it's parentform when clicked.
Bart wrote 13 lines
On 4/25/12, patspiper wrote: > As for TBitBtn, I suggest Lazarus respects the button's modalresult and > acts accordingly. > By default a Button with ModalResult = mrNone will not close it's parentform when clicked. A TBitBtn with Kind = bkClose and ModalResult is the exception to this rule. It should close the parentform, not setting it's ModalResult (which will result in ModalResult of parentform being mrCancel). A TBitBtn with ModalResult mrNone should always set parentform's ModalResult (regardless of Kind), which is what my patch does.

To summarize, your target is:

1- TBitButton:

a- TBitButton with ModalResultmrNone: Its ModalResult will act normally (close form and set its ModalResult to the BitButton's ModalResult).

b- TBitButton with KindbkClose and ModalResult=mrNone: Does nothing.

c- TBitButton with Kind=bkClose and ModalResult=mrNone: Close form and set its ModalResult to mrCancel.

2- Native PromptUser():

a- Escape and [x] close the dialog and return mrCancel

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.

IMHO:

- 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. I can't see why he would set it as mrNone and expect it to act as mrCancel.

- 2a is logical

- 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). Furthermore, I wonder how mbAbort is excluded. The current behaviour of MessageDlg under gtk2 is as described below. I suggest this is considered for the Escape key.
-------------------------------
Escape and [x] border icon are equivalent and always return the same modal result. They will return the following in high to low order of preference (assuming the corresponding button is present): mrCancel
mrNo
mrAbort
mrIgnore
mrNoToAll
mrYes
mrOK
mrRetry
mrAll
mrYesToAll

If the only button in MessageDlg is mbClose, then Escape or [x] will return mrCancel. This corresponds exactly to what the ModalEscapeValue function does.
-------------------------------

Stephano

Reply by email

Bart
to patspiper
patspiper 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)

- 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

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.

Show quoted text 7 lines
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 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).

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

Bart

Reply by email

patspiper
to Bart
Bart wrote 8 lines
On 4/27/12, patspiper 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.

Show quoted text 7 lines
> - 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.

Show quoted text 9 lines
> 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.

Show quoted text 32 lines
> 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

Reply by email

Bart
to patspiper
patspiper wrote
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.

And they do. Just bkClose without mrNone did not act as expected. This is what I fixed.

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

Well, the look and feel (for the end-user) will differ of course. In hindsight, when the Borland guys first made Delphi, it would have been easier if they had decided to return mrCancel when user presses Escape.

Now we carry the burden of backwards compatibility...

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

There are valid arguments for both option 1 and 2. And, Delphi compatibility isn't the holy grale AFAIAC. Current implementation (without my patches) however is IMHO wrong.

Let's hear from the core devels.
I'm happy to code it either way.

Bart

Reply by email

Bart
to patspiper: I was referring to the end result, not the mechanism. Same comment as above. Lazarus…

Here's the alternative implementation: Escape will always return mrCancel, both LCL's own CreatemessageDialog and
Widgetset.PromptUser().

See attached file: msgdlg.alternative.diff
(Diff's for the first solution are in the bugtracker)

Bart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msgdlg.alternative.diff
Type: text/x-patch
Size: 3547 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120428/6f786caf/attachment.bin>

Reply by email

patspiper
to Bart: And they do. Just bkClose without mrNone did not act as expected. This is what I fixed.…
Bart wrote 8 lines
On 4/27/12, patspiper wrote: > 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. And they do. Just bkClose without mrNone did not act as expected. This is what I fixed.

Logically speaking, any button/bitbutton with mrNone should have no ModalResult effect.
Furthermore, I checked Embarcadero's online help, but could not find any reference to the behaviour you described for mbClose with mrNone.

Steohano

Reply by email

patspiper
to Bart: Here's the alternative implementation: Escape will always return mrCancel, both LCL's own…
Bart wrote 6 lines
Here's the alternative implementation: Escape will always return mrCancel, both LCL's own CreatemessageDialog and Widgetset.PromptUser(). See attached file: msgdlg.alternative.diff (Diff's for the first solution are in the bugtracker)

IMHO, the alternative implementation is very logical as:
- Both types of dialogs are consistent
- The programmer doesn't have to refer to documentation to find out what the Escape key does for every combination of buttons, and its effect on the dialog result

In any case, good work Bart!

Stephano

Reply by email

patspiper
to Bart: Here's the alternative implementation: Escape will always return mrCancel, both LCL's own…
Bart wrote 6 lines
Here's the alternative implementation: Escape will always return mrCancel, both LCL's own CreatemessageDialog and Widgetset.PromptUser(). See attached file: msgdlg.alternative.diff (Diff's for the first solution are in the bugtracker)

This alternative implementation seems to be in line with Delphi XE's result for MessageDlg('test', mtInformation, [mbOk, mbAbort], 0) when Escape key is pressed: mrCancel

Stephano

Reply by email

zeljko
to patspiper
patspiper wrote 11 lines
On 28/04/12 13:37, Bart wrote: > Here's the alternative implementation: Escape will always return > mrCancel, both LCL's own CreatemessageDialog and > Widgetset.PromptUser(). > > See attached file: msgdlg.alternative.diff > (Diff's for the first solution are in the bugtracker) This alternative implementation seems to be in line with Delphi XE's result for MessageDlg('test', mtInformation, [mbOk, mbAbort], 0) when Escape key is pressed: mrCancel

hm...just fixed qt part for EscapeButton, but when testing QuestionDlg() seem that Cancel = True maps one button as cancel result (Escape or [x]) under gtk2 and qt eg. QuestionDlg('Confirm','Please confirm me', [mrYes,'Yes',mrAbort,'Abort'],0) returns mrAbort when escape key or [x] is clicked.
If we are following behaviour of MessageDlg, QuestionDlg should return mrCancel in any case when Escape key is pressed or [x] is clicked. Anyone can test what QuestionDlg() is doint under Delphi XE ?

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/39734b5b/attachment.html>

Reply by email

Bart
to zeljko: hm...just fixed qt part for EscapeButton, but when testing QuestionDlg() seem that Cancel…
zeljko wrote
hm...just fixed qt part for EscapeButton,

Sorry, I am unable to test all widgetsets.

Show quoted text 7 lines
but when testing QuestionDlg() seem that Cancel = True maps one button as cancel result (Escape or [x]) under gtk2 and qt eg. QuestionDlg('Confirm','Please confirm me', [mrYes,'Yes',mrAbort,'Abort'],0) returns mrAbort when escape key or [x] is clicked.

I didn't look into QuestionDlg.

(I never used that)

If we are following behaviour of MessageDlg, QuestionDlg should return mrCancel in any case when Escape key is pressed or [x] is clicked. Anyone can test what QuestionDlg() is doint under Delphi XE ?

With [mrYes,'Yes',mrAbort,'Abort'] it should not respond to Escape if it is our own built form (like MessageDlg does now), it should return mrCancel on [X]-bordericon.

Do we have specific (native) widgetset implementations for QuestionDlg, or is it a LCL built form?

Bart

Reply by email

zeljko
to Bart
Bart wrote 27 lines
On 4/29/12, zeljko wrote: > hm...just fixed qt part for EscapeButton, Sorry, I am unable to test all widgetsets. > but when testing QuestionDlg() > seem > that Cancel = True maps one button as cancel result (Escape or [x]) under > gtk2 > and qt eg. QuestionDlg('Confirm','Please confirm me', > [mrYes,'Yes',mrAbort,'Abort'],0) returns mrAbort when escape key or [x] > is clicked. I didn't look into QuestionDlg. (I never used that) > If we are following behaviour of MessageDlg, QuestionDlg should return > mrCancel in any case when Escape key is pressed or [x] is clicked. > Anyone can test what QuestionDlg() is doint under Delphi XE ? With [mrYes,'Yes',mrAbort,'Abort'] it should not respond to Escape if it is our own built form (like MessageDlg does now), it should return mrCancel on [X]-bordericon. Do we have specific (native) widgetset implementations for QuestionDlg, or is it a LCL built form?

LCL decides about Cancel button and sends to WS AskUser() , whatever that means.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/0a77390b/attachment-0001.html>

Reply by email

patspiper
to Bart: Mind you, the first implementation is in line with Delphi XE on all platforms, the…
Bart wrote 7 lines
On 4/29/12, patspiper wrote: > This alternative implementation seems to be in line with Delphi XE's > result for MessageDlg('test', mtInformation, [mbOk, mbAbort], 0) when > Escape key is pressed: mrCancel Mind you, the first implementation is in line with Delphi XE on all platforms, the alternative only with Delphi XE on Vista and higher.

Does Lazarus need different results depending on the OS? Does the developer have to worry about which Windows version is running and code accordingly? On the other hand, porting code from Delphi will need modifications anyway, and hence time could be spent on streamlining the behaviour.

My suggestion was to have the Lazarus implementation the same as Delphi XE's on Vista and higher, and hence your alternative implementation.

Stephano

Reply by email

patspiper
to zeljko: hm...just fixed qt part for EscapeButton, but when testing QuestionDlg() seem that Cancel…
zeljko wrote 33 lines
On Sunday 29 of April 2012 10:40:18 patspiper wrote: > On 28/04/12 13:37, Bart wrote: > > Here's the alternative implementation: Escape will always return > > mrCancel, both LCL's own CreatemessageDialog and > > Widgetset.PromptUser(). > > > > See attached file: msgdlg.alternative.diff > > (Diff's for the first solution are in the bugtracker) > > This alternative implementation seems to be in line with Delphi XE's > result for MessageDlg('test', mtInformation, [mbOk, mbAbort], 0) when > Escape key is pressed: mrCancel hm...just fixed qt part for EscapeButton, but when testing QuestionDlg() seem that Cancel = True maps one button as cancel result (Escape or [x]) under gtk2 and qt eg. QuestionDlg('Confirm','Please confirm me',[mrYes,'Yes',mrAbort,'Abort'],0) returns mrAbort when escape key or [x] is clicked.

It could be following the function ModalEscapeValue, ie return the following in high to low order of preference (assuming the corresponding button is present):
mrCancel
mrNo
mrAbort
mrIgnore
mrNoToAll
mrYes
mrOK
mrRetry
mrAll
mrYesToAll

If the only button in MessageDlg is mbClose, then return mrCancel.

If we are following behaviour of MessageDlg, QuestionDlg should return mrCancel in any case when Escape key is pressed or [x] is clicked.

+1
Unifying [x] and Escape key to mrCancel is IMHO the most logical.

Anyone can test what QuestionDlg() is doint under Delphi XE ?

I currently don't have access to Delphi to test.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/40354887/attachment-0001.html>

Reply by email

patspiper
to Bart: Sorry, I am unable to test all widgetsets. I didn't look into QuestionDlg. (I never used…
Bart wrote 22 lines
On 4/29/12, zeljko wrote: > hm...just fixed qt part for EscapeButton, Sorry, I am unable to test all widgetsets. > but when testing QuestionDlg() > seem > that Cancel = True maps one button as cancel result (Escape or [x]) under > gtk2 > and qt eg. QuestionDlg('Confirm','Please confirm me', > [mrYes,'Yes',mrAbort,'Abort'],0) returns mrAbort when escape key or [x] is > clicked. I didn't look into QuestionDlg. (I never used that) > If we are following behaviour of MessageDlg, QuestionDlg should return > mrCancel in any case when Escape key is pressed or [x] is clicked. > Anyone can test what QuestionDlg() is doint under Delphi XE ? With [mrYes,'Yes',mrAbort,'Abort'] it should not respond to Escape if it is our own built form (like MessageDlg does now), it should return mrCancel on [X]-bordericon.

Standardise as much as possible.

Stephano

Reply by email