Last week someone on Flexcoders was having trouble with a popup window triggering commands in the Cairngorm framework for Flex 2. At the risk of repeating myself, I'm reproducing the answer here because it was on my "things to blog" list, and also because it should make finding the answer with search engines a bit easier.
Here is an illustration of the problem:
// This code goes inside of a class that gets opened via PopUpManager.createPopUp, // such as a subclass of TitleWindow var event:MyEvent = new MyEvent ( data ); // MyEvent extends CairngormEvent dispatchEvent( event );
Normally, the above code would cause the FrontController to handle the event in the normal Cairngorm manner (by invoking the Command associated with the event). However, when the event is dispatched from a popup window, nothing happens. Changing the code to the following fixes the problem:
// This code goes inside of a class that gets opened via PopUpManager.createPopUp, // such as a subclass of TitleWindow var event:MyEvent = new MyEvent ( data ); // MyEvent extends CairngormEvent Application.application.dispatchEvent( event );
By dispatching the event from the application reference, the FrontController behaves how you would expect.
So what causes the unexpected behavior in the original code? The answer lies in the class hierarchy at runtime, and the nature of event bubbling.
The reason the FrontController doesn't pick up the event in the first case is because even though the event will bubble up the display list, the application itself is not in the same display branch as the popup window. The event therefore never reaches the application, and the FrontController thus can not handle it. Visually, the runtime structure of your application might look something like this:
Unlike what you may expect, the application itself is not the root of the display list. When popup windows are created, they are not created on the same branch of the application, but rather they are created under the root display class, SystemManager. This makes the popup effect simple -- apply a blur filter over the entire application branch and keep the mouse and keyboard focus on the branch with the popup window. The popup window appears "on top" because of the nature of the new display list model, and it turns out to be relatively easy to make the window appear modal.
So, when you dispatch an event from one of the regular Child Forms, the event will bubble up to the application and the FrontController will handle it as it normally would. When you dispatch an event from a popup, the event still bubbles up, but it never passes by the application instance and therefore the FrontController can never map it to a command. By forcing the event to be dispatched from the application instance itself (in the second code block, above), the event is sure to pass through the application and thus the FrontController will be able to handle it.
For now, this behavior is a "Fact of Life" (FOL). It's just the way the PopUpManager works, and it's something to keep in mind when using Cairngorm 2. Future versions of the framework may come up with a more graceful way to handle this scenario, but for now, dispatching the event from the application is the way to go.
Tags: ActionScript, Flex, Flex 2, Cairngorm

2 Comments
Why not addEventListener to the PopUpManager instance also using "addEventListener(commandName,executeCommand);"
Would that not install listeners for the FrontController at both "displayList" trees so bubble would STILL work?
Posted by: Thomas Burleson | May 4, 2006 10:16 PM
As of Cairngorm 2.2, use myEvent.dispatch(); instead to propagate the CairngormEvent through the application.
http://weblogs.macromedia.com/amcleod/archives/2007/05/cairngorm_22_-.cfm
Posted by: darron | May 24, 2007 1:19 PM