Why are accelerators for hidden controls still active?
In the suggestion box, Serge Wautier asked why accelerators for hidden controls remain active. He’s apparently rather insistent because he asked the question again a few months later. Asking the same question multiple times reduces the likelihood that I’ll answer it. Consider yourself lucky that I wrote this answer before I noticed the duplicate; otherwise I would probably have skipped it.
Why are accelerators for hidden controls still active? Very simple: Keyboard accessibility.
The dialog manager considers controls which indicate
that they want characters
(DLGC_WANTCHARS)
to have no keyboard accelerator.
There are a lot of controls that fall into this category,
including such popular ones as edit controls,
combo boxes, and list boxes.
The traditional way of giving these “no accelerator” controls
an accelerator is to stick a static control on front of it
with the desired accelerator:
LTEXT "Ca&pacity:",IDC_STATIC,7,6,31,9
COMBOBOX IDC_CAPACITY,7,40,150,300,
CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP
But what if you don’t want a label to appear in front of the control? For example, the General property page of a file begins with an unlabeled edit control that contains the name of the file. You might have a dialog that contains a list view that you don’t want to label because its meaning is implied by other controls on the page or by the page layout.
The answer is to hide the label control but leave it enabled. This keeps the accelerator active, allowing the user to press the accelerator to put focus on the edit control or list view or whatever, but removes the actual accelerator indicator from the screen.
This means that if you want to take a control off the dialog because you don’t want the user to invoke it at all, merely hiding it won’t be enough, since the accelerator is still active. In addition to hiding the control, you also have to disable it. (Alternatively, you could destroy the control.)
Light
Dark
0 comments