OptionKey madness

[Richard Gaskin]

Frank Leahy wrote:

>>> This works as expected on my machine (Mac OSX, 10.2.8) -- all keycodes
>>> come through and the optionKey is correct when up and down.
>>>
>>> on rawKeyDown whichKey
>>>  put "raw key " & whichKey && the optionKey
>>>  pass rawKeyDown -- same with or without this
>>> end rawKeyDown
>>
>> Did you try typing the keystrokes into a field?
> 
> Nope, doesn't work in a field.
> 
> Having worked at Apple, the feeling was that the command key and 
> function keys are for user input (menus, and user or app choosable 
> functions respectively).

With OS vendors it's sometimes a case of "do as I say, not as I do":

Exhibit A is the control panel in Windows in which you set the font size
for controls -- that control panel ignores those settings.  :)

Exhibit B is the set of pre-assigned Function keys in OS X:  F9, F10,
and F11 are for Exposé, and on PowerBooks F1 through F6 have other
pre-assigned behaviors, and F7 toggles Ful Keyboard Access in windows
and dialogs, leaving only two keys (F8 and F12) for reliable use by Mac
developers for user input.

For the moment I'm using Cmd(Mac)/Ctrl(Win) 1 through 0 for one set of
features, and will choose ten alphabetical Cmd/Ctrl keys for the other
10 features.


> And there's the question of what happens if someone wants to type
> a bullet character into the field with option-8, is Richard not
> going to let the bullet character appear in the field?

Wouldn't Apple consider inputting text to be part of "user input"?

Yes, I'm familiar with that Apple-specific anomaly, my second-favorite
after the audio-in jack. :)

In this particular case users won't be typing bullets in this app, but
it's no longer an issue at all since I'm now doing everything with
Cmd/Ctrl keys only.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com