3

I recently realized that the Windows dialog manager apparently honors mnemonics to controls that aren't visible. For example, if I hide a button labeled "&Foo" on a dialog via ShowWindow(SW_HIDE), pressing Alt+F triggers the button.

Why does Windows do this? (I'm guessing that long ago some developer somewhere perhaps used a hidden control as a poor-man's way to implement hidden keyboard shortcuts, and this unintuitive behavior has been preserved for the sake of backward compatibility.)

More importantly: before I go through our entire codebase to audit all ShowWindow sites and to make them explicitly disable hidden controls, is there any decent way to adjust this behavior in the dialog manager? I'm somewhat surprised that I haven't been able to find much information/complaining about this; the best I could find is what looks like an old Microsoft KB article archived by a third-party that recommends to override each control's WM_GETTEXT handler by subclassing. (That seems rather heavy-handed thing to do for every control that might be hidden.)

(Also note that that article discusses disabled controls, not hidden ones, so the dialog manager doesn't ignore disabled controls either. This can also be observed by creating a hidden, disabled checkbox that shares a mnemonic with a visible, enabled one. Pressing the mnemonic key moves focus to the visible checkbox but does not toggle it as it normally would, just as it would for a typical case of a mnemonic collision.)

jamesdlin
  • 81,374
  • 13
  • 159
  • 204
  • Could you be confusing keyboard accelerators with mnemonics? When experimenting about your question, I have realized a peculiar menu behavior that can be related: When, for example, File menu item is open in a Windows (7) application, if you press the mnemonic of a disabled item, the menu closes. This does not happen if you press a button that does not correspond to any of the mnemonics defined in that menu. This can also give a hint about how to handle mnemonics (it looks like Windows developers chose to close the parent menu). – simurg Mar 11 '15 at 07:35
  • 3
    [Why are accelerators for hidden controls still active?](http://blogs.msdn.com/b/oldnewthing/archive/2008/06/02/8568490.aspx) – IInspectable Mar 11 '15 at 08:48
  • @simurg Normally when I think of "accelerator", I think of an `ACCELERATORS` resource used with `TranslateAccelerator` (e.g. Ctrl+O). I'm talking about mnemonics (the underlined access keys), which is what [MSDN's page on dialog boxes](https://msdn.microsoft.com/en-us/kb/ms644995%28v=vs.100%29.aspx#mnemonics) also calls them. – jamesdlin Mar 11 '15 at 09:20
  • @IInspectable Ah, I had been searching Raymond Chen's weblog but couldn't find that article (probably because I was searching for "mnemonic" rather than "accelerator"). Thanks. However, I do find that explanation to be a bit unsatisfying since it doesn't quite explain why they're enabled for hidden *buttons*. – jamesdlin Mar 11 '15 at 11:22
  • @James: Hiding a control changes its visibility. Disabling a control blocks user input. Conditionally changing those simple rules, for some controls, while applying them to others makes the resulting ruleset needlessly complex. If you want to disable hidden controls, you know how to do it. Although I'm having a feeling that keyboard accessibility wasn't the reason to install the rules as they are, rather, that the existing rules allow to provide (invisible) keyboard accessibility to controls that were otherwise inaccessible. – IInspectable Mar 11 '15 at 14:38
  • @IInspectable But disabling hidden controls isn't enough either. If you have a hidden, disabled control, it will generate a mnemonic conflict with a visible, enabled control. Regarding conditional rules, static controls are *already* special since the dialog manager must focus the next control. Having hidden controls honor mnemonics at all IMO is an unintuitive pitfall, and the benefit it offers is undiscoverable anyway. – jamesdlin Mar 11 '15 at 18:14

0 Answers0