Mac Forum / Programming / Mac Programming / September 2007

The scenario:
My application has a window open. The app/window needs to know about
keys being hit - It's not using them as data, storing them, etc - the
keys are controlling program behavior, so it's not actually "text
input". There is no dialog/control active, no special handling required,
it doesn't need unicode, and has no interest in modifiers. It just needs
a Carbon Event based equivalent of this Pre-MacOS X style routine:

WaitNextEvent(keyDownMask|autoKeyMask, &EventGotten, etc...);
if (EventGotten == KeyDownEvent)
  {
     // inspect the key that was hit. If it's one we're interested
     // in, eat it and do something in response to it.
  }

But without the "sins" involved in using WaitNextEvent().

After digging around in the docs, my first instinct is to install a
handler on the window to catch kEventClassKeyboard/kEventRawKeyDown
events and go from there, but according to those same docs, this is a
"Bad Thing(TM)" to do, and the suggestion is to go through the TSM to
get it instead.

I don't want the TSM. I don't need the TSM. I simply want the key the
user pressed, with as little hassle and overhead as possible. If it's
not one of the keys I'm looking for, I'm perfectly willing to (and in
fact, have already coded to do so) CallNextEventHandler() and let
"somebody else" deal with it. If it IS a key I'm looking for, I have
every intention of eating it and ending the handling of the event that
generates it in my handler through the usual "return noErr" method.

So, with that in mind, is it still a "Bad Thing(TM)" to grab the
RawKeyDown event?

Or is there actually some pressing reason for me to go through the TSM?

(And if so, why does Apple provide the RawKeyDown event in the first
place?!?!? It seems like this event would be ideal for what I need to
do, but the "you shouldn't do this" warning leaves me wondering)