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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20040814/10e495a9/attachment.htm