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