Agree with Ryan, and I'd add that I've sometimes found it helpful, when handling keyboard events in general, to wire up my listeners to the event's capture phase, rather than the target or bubbling phases (note the third argument, false by default):
stage.addEventListener(KeyboardEvent.KEY_DOWN, handleKeyDown, true);
Thinking for instance of a casual game in which the arrow keys control the core action somehow (Tetris, maybe -- rotate left, rotate right), responding to an event during the capture phase means can have distinct advantages. From the docs:
In the capturing phase, Flex examines
an event's ancestors in the display
list to see which ones are registered
as a listener for the event. Flex
starts with the root ancestor and
continues down the display list to the
direct ancestor of the target. In most
cases, the root ancestors are the
Stage, then the SystemManager, and
then the Application object.
So in this case, you can be sure the stage's listener will get the notification first, before anyone else, and can respond accordingly -- either by terminating the event-propagation entirely (sometimes you might want to do that) or by translating it into a more application-specific, custom event:
private function handleKeyDown(event:KeyboardEvent):void
{
if (event.keyCode == Keyboard.LEFT)
{
dispatchEvent(new Event("rotateLeft"));
}
else if (event.keyCode == Keyboard.RIGHT)
{
dispatchEvent(new Event("rotateRight"));
}
else
{
event.stopPropagation();
}
}
... and keeping you from peppering keyboard listeners all over your app.
Event-propagation phases are described in more detail here. Check it out as well -- there's great info in there that's well worth knowing.