Re: [Audacity-devel] irritating bug in Keyboard Preferences when seeking to the next command by hitting a keyboard character

[Bill W. <bi...@go...>]

> [snip]

> [Ed:]
> On Windows, the tab key should not be allowed as a shortcut key. The
> OnKeyDown function should immediately examine the event and  
> determine if it
> is the tab key (or any other inappropriate key); if so, it should exit
> immediately passing the event up the event handler chain.

And the same should happen for Mac and Linux, IMO.

> I get the
> impression from your above paragraph that the <ALT> key works the  
> same way
> in Linux as the <TAB> key does in Windows, is this accurate? Does  
> the Mac
> have a keyboard shortcut which brings focus to the next  
> "thing" (button,
> list box -- whatever)?
>

On Mac, the TAB key is used to move keyboard focus from one element to  
the next. My understanding about Gale's mention of the ALT key is that  
the ALT key is used for the "accelerator" functions (e.g. ALT-S  
"presses" the "Set" button). On Mac, that would be OPTION-S, I assume.  
With focus on the text box, pressing ALT or OPTION clears the text box  
in preparation for accepting whatever key combination the user is  
about to enter. On my Mac pressing SHIFT, CTRL, or COMMAND also clears  
the text box if it has focus. Why it does this is a mystery to me. Why  
not wait until an actual, valid key combination is pressed to update  
the text box? This still means that *all* accelerators would not work  
when the text box has focus, or the user would not be able to set a  
shortcut of the form ALT-<key> or OPTION-<key>.

-- Bill