On Tue Aug 19 15:11:05 2025 +0000, Nikolay Sivov wrote:
It's more complicated than that. There are dedicated messages WM_QUERYUISTATE/WM_UPDATEUISTATE/WM_CHANGEUISTATE. So this state is dynamic, but probably changes only one way. On modern Windows you don't get focus rectangles by default on buttons, but you can get them by pressing "Alt", that's how it worked from when this UI change was introduced. It applies both for focus rectangles and keyboard accelerators. What I imagine we need is to send WM_CHANGEUISTATE to a top level window, let default procedure propagate it using WM_UPDATEUISTATE, and then react accordingly in controls. Button v6 (or maybe all controls in v6 variants) works differently - newly created button does not have a focus rectangle, until you press Alt. User32 button "inherits" this state probably, and creating new button shows focus rectangle right away.
I am aware of WM_UPDATEUISTATE, but I didn't know that pressing Alt could turn on the focus rectangles dynamically. And I thought since we don't support WM_QUERYUISTATE/WM_UPDATEUISTATE/WM_CHANGEUISTATE in Wine at the moment, we could just use the sysparam state.
On Windows 10 22H2, you call SystemParametersInfoW(SPI_SETKEYBOARDCUES, 0, 1, 0) to turn on keyboard cues. And then comctl32 v6 buttons will have a focus rectangle by default, without pressing Alt. This seems to contradict what you said about comctl32 v6 button not showing a focus rectangle until Alt is pressed.
Even with Alt being able to turn on focus rectangles dynamically, I am not sure it's worth it to add support for WM_QUERYUISTATE/WM_UPDATEUISTATE/WM_CHANGEUISTATE and Alt handling in DefWindowProc(). The focus state can be manifested by the theme part state now. So having a focus rectangle is actually redundant.
Anyway, what I am trying to say is that I would like to delay implementing WM_QUERYUISTATE/WM_UPDATEUISTATE/WM_CHANGEUISTATE and Alt handling until a real-world application needs it.