Constructor...and...and

Well, it turned out to be more complicated than "it's the constructor, stupid."

For keyboard events, at least, the event handler has to be installed in the view's application's stage. Unfortunately, the view's application and stage are both "null" when the view's constructor is called.

Therefore, in the view's constructor, I added a listener for the view's "creationComplete" event, which is dispatched at the very end of the view's creation and initialization process.

public function MyView()
{
super();

addEventListener(mx.events.FlexEvent.CREATION_COMPLETE,

creationCompleteHandler);
}

When the view's "creationComplete" message handler is called, the view's application is initialized, but it's stage isn't. So, in the view's "creationComplete" message handler, I added a listener for the application's "applicationComplete" message.

public function creationCompleteHandler(e:Event): void {
parentApplication.addEventListener(FlexEvent.APPLICATION_COMPLETE,

  applicationCompleteHandler);
}

Finally, in the "applicationComplete" handler, the view's application's stage is initialized, allowing me to install listeners for keyboard events, which was the whole purpose of the exercise.

public function applicationCompleteHandler(e:Event): void {
parentApplication.stage.addEventListener(KeyboardEvent.KEY_DOWN, keyHandler);
parentApplication.stage.addEventListener(KeyboardEvent.KEY_UP, keyHandler);
}

This solution requires two "preparatory" layers of event listeners just to get to a point in the initialization cycle where the view's application's stage's state is stable. It strikes me as being an obscure kludge rather than an elegant design. Its only virtue is that is honors encapsulation. It reaches *up* into its super-classes' properties (parentApplication and parentApplication.stage), which is perfectly legit.

The only other solution I could think of was to install the keyboard listener within the scope of the application's code, rather than the view's. This, however, would require having the application "know about" its sub-view's keyHandler function -- that is, reaching *down* into a component's implementation details, which is a heinous violation of encapsulation.

If anyone knows of a cleaner solution, I'd love to hear about it.