Windows Default Button Observations

[Zach Gorman]

While fixing some compatibility problems in Wine relating to my app, I had
the opportunity to compare how Wine handles default buttons to how Windows
handles them. [Definition: Default buttons have the BS_DEFPUSHBUTTON style,
are drawn with an extra-thick border, and are the buttons chosen when the
user types Enter.] I fixed a couple problems today, but there are more
issues left:

-------

(1)

Windows: When a dialog is deactivated in Windows, all buttons are made
non-default. When it is activated again, Windows remembers which button was
last the default button and makes it default again. It does all this by
means of BM_SETSTATE messages.

Wine: Default buttons are unaffected by activation/de-activation of their
parent dialogs.

(2)

Windows: When the user clicks and holds on a button, then moves the mouse
off that button before releasing it, the button is made default and receives
the focus. The existing default button is made non-default.

Wine: The button receives the focus but is not made default.

--------

My impression is that (1) could be handled by remembering the default button
(which, as Krishna Murthy has shown, is not the same as the default button
id) in the DIALOGINFO structure.

Number (2), however, is more difficult. When a button receives the capture,
it can send a BM_SETSTATE to itself easily enough to make itself a
DEFPUSHBUTTON, but how does it determine which other buttons to query and
make non-default as necessary? It could simply query all its sibling
controls, but this wouldn't work if it was contained within a sub-window in
the dialog box. How can it determine how far up the hierarchy it needs to
go?

Any comments would be welcomed.

Thanks,

Zach

[Ferenc Wagner]

"Zach Gorman"  writes:
> My impression is that (1) could be handled by remembering
> the default button (which, as Krishna Murthy has shown, is
> not the same as the default button id) in the DIALOGINFO
> structure.
>
> Number (2), however, is more difficult. When a button
> receives the capture, it can send a BM_SETSTATE to itself
> easily enough to make itself a DEFPUSHBUTTON, but how does
> it determine which other buttons to query and make
> non-default as necessary?

Once you remembered the current (possibly inactive) default
button in DIALOGINFO, this should come for free.  I hope at
most one button can be default in a dialog...

[Mike Hearn]

On Sun, 15 Aug 2004 11:23:07 +0200, Ferenc Wagner wrote:
> Once you remembered the current (possibly inactive) default
> button in DIALOGINFO, this should come for free.  I hope at
> most one button can be default in a dialog...

http://weblogs.asp.net/oldnewthing/archive/2004/08/02/205624.aspx

I'm afraid it's possible for dialogs to have more than one default button.
That is a good post on management of default buttons in dialog boxes,
here's another related to focus:

http://weblogs.asp.net/oldnewthing/archive/2004/08/04/208005.aspx#FeedBack

thanks -mike

[Ferenc Wagner]

Mike Hearn  writes:
> On Sun, 15 Aug 2004 11:23:07 +0200, Ferenc Wagner wrote:
> > Once you remembered the current (possibly inactive) default
> > button in DIALOGINFO, this should come for free.  I hope at
> > most one button can be default in a dialog...
>
> http://weblogs.asp.net/oldnewthing/archive/2004/08/02/205624.aspx
>
> I'm afraid it's possible for dialogs to have more than one
> default button.

No, there is no hope. :(  This fancy feature is definitely
worth supporting in Wine.  Thanks for the correction.

[Zach Gorman]

> Once you remembered the current (possibly inactive) default
> button in DIALOGINFO, this should come for free.  I hope at
> most one button can be default in a dialog...

In Windows, when you click & hold on a button, each button in the dialog
gets sent a WM_GETDLGCODE, presumably to determine whether it is a
DLGC_DEFPUSHBUTTON or a DLGC_UNDEFPUSHBUTTON. Any button that returns
DLGC_DEFPUSHBUTTON is sent a BM_SETSTYLE to make it non-default
(BS_PUSHBUTTON, not BS_DEFPUSHBUTTON).

The main issue here seems to be separation of button code from dialog code.
It would seem that the dialog code should be responsible for sending the
WM_GETDLGCODE messages to the dialog's children, but how is the dialog code
told to do this? The only messages the dialog itself receives in response to
the LBUTTONDOWN on the button are WM_MOUSEACTIVATE, WM_SETCURSOR, and
WM_CTLCOLORBTN. I don't think it is any of these messages that causes the
dialog to start un-defaulting its child buttons.

Zach