On Tue Aug 19 15:11:05 2025 +0000, Zhiyi Zhang wrote:
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.
I haven't tried with SPI_SETKEYBOARDCUES, I was talking about defaults.
Disabling cues unconditionally or by this parameter that users don't interact with, is wrong. This will make it impossible for people to use keyboard navigation in dialogs for example.
Not implementing this with correct messages will also potentially create inconsistent behavior between any custom controls, and system provided controls.