On Tue Jun 13 20:11:52 2023 +0000, Esme Povirk wrote:
This is going to be an accessibility problem because it prevents keyboard access of the toolbar. What I meant with my earlier suggestion was to restore the focus after passing WM_LBUTTONDOWN/WM_LBUTTONDBLCLK messages to the button's wndproc, but that's not ideal either because it still leaves us with spurious focus changes. My suggestion now is to have the subclass procedure handle WM_LBUTTONDOWN/WM_LBUTTONDBLCLK by passing a WM_KEYDOWN message with VK_SPACE to the button procedure. Based on reading the Wine source code and manual testing on Windows, this should give identical behavior without changing the focus. I would also suggest giving toolbar buttons the WS_TABSTOP style. Windows allows me to tab to those buttons in the item dialog.
Oh, WM_KEYDOWN is a neat trick, it do be working, not so well with split button dropdown, but that's fine.
Agonized over that for a bit, then realized that even Windows seem to take focus when opening the dropdown, and clicking on it is going to open address edit later.
Also added required window flags to get tab navigation working and dropped the hacks.