In Chapter 3 we discuss the new event model and many of its new features. Over the next few posts we'll dig a little deeper and look at some of the more detailed aspects of dealing with events. Here, we'll talk about event phases and how they work.
Below is a visual example of how the capture, target, and bubble phases work together. Click on the files and folders to see a path of event propagation, but pay close attention to the Event Summary field to see which phases are being executed, and in what order.
You may want to come back to this demo a few times as you read about what it's doing.
This demo is meant to show the order in which the event phases occur under normal circumstances. No matter which movie clip you click on, the capture phase (shown in red) will always start at the stage. Let's assume you click on file0 within the bigFolder movie clip, which will trigger a MOUSE_DOWN event. The Flash player will first check to see if there are any registered MOUSE_DOWN event listeners added to the stage and, if there are, it will run their functions.
Next the player looks at bigFolder and checks to see if that clip has any registered MOUSE_DOWN event listeners. If it finds any, the player will execute those listener functions. Continuing down the display list, the Flash player enters the target phase (shown as a single event in purple) and checks to see if the target (file0) has any registered MOUSE_DOWN listeners.
After any MOUSE_DOWN listeners associated with file0 are run, the player enters the bubble phase (shown in blue) and starts moving back up the display list. The clip bigFolder is checked again and, lastly, the stage is checked again, both times looking for any registered MOUSE_DOWN event listeners. If any are found, their functions will be executed.
Listening for the Capture Phase is Pretty Rare
This may sound like a lot to think about, but event phases don't have to be a big concern in your everyday scripting. More often than not, you'll find yourself using the target event phase—the default behavior, and a typical scenario when clicking on a button, for example.
DEFAULT BEHAVIOR: TARGET/BUBBLE ONLY
In its most basic form, a listener might be added like this:
btn.addEventListener(MouseEvent.CLICK, onBtnClick);
This form uses no additional optional arguments and, by default, does not use the capture phase. For slightly improved memory management (not as a substitute for properly removing listeners), we advocate weakly referenced listeners (see page 47 in the book for more information), so we suggest the following usage:
btn.addEventListener(MouseEvent.CLICK, onBtnClick, false, 0, true);
The last optional argument enables the weak reference but, to use it, we must insert the default values for the other two options—false for the useCapture argument, so the capture phase is not used, and 0 for priority, which we'll discuss in the next post.
Let's take a look at our demo again, this time without the capture phase. Again, pay attention to the Event Summary field to see that nothing is listening during the capture phase.
CAPTURE ONLY
Although use of the capture phase will likely be rare, it's still helpful to know what it is and how to put it to work. As the previous code snippets suggest, enabling the capture phase requires only that you change the useCapture argument to true:
btn.addEventListener(MouseEvent.CLICK, onBtnClick, true, 0, true);
This approach will only listen for the capture phase and won't listen for target or bubble, which is an important thing to understand. Through the use of the useCapture parameter, you can listen for only the capture phase (when set to true), or only the target and bubble phases (when set to false, the default). To listen for both phases, as demonstrated in the first example in this post, you must use two listeners. Here is what our hypothetical button example would look like when set to listen to all phases:
btn.addEventListener(MouseEvent.CLICK, onBtnClick, true, 0, true); btn.addEventListener(MouseEvent.CLICK, onBtnClick, false, 0, true);
As stated earlier, you may not use the capture phase very often, at least initially. So, try an experiment or two to get comfortable with it, and then you'll be ready when you need it. For a creative way to use this feature, see the "Interesting Use of Capture Phase" post.
Print This Post


(7 votes, average: 4.86 out of 5) 






























So looking at the code for event_propagation2.fla confuses me a bit. I was under the impression that doing what you do here would make all the children of that mc change alpha when the mouse is over the group, but they don't. Only the folder mc under the mouse does change its alpha. So if I use 'this' instead of 'evt.target' the entire group changes alpha at the same time. So 'evt.taget' goes deep into a group of nested objects on the stage and always refers to the item that is being interacted with specifically?
@Rodney, you've got it. There are three things you can focus on in this scenario. The first is the use of the this keyword. That keyword can be thought of as "self-referential." That is, it refers to the item/scope that the script is referencing. In this example, this refers to the object to which the listener is attached. Therefore, the folder_group movie clip that encloses all the folders is the object that is faded.
The second thing is the event target. By using the target property of the evt parameter, you can determine which item triggered the listener--in this example, which item was rolled over or rolled out of. This handy property allows you to find only the object with which the user interacted, even when the event is cascading down, or bubbling up, through the display list.
A third property, not referenced in this example, is also sometimes useful. It is called currentTarget and tells you which display object is processing the event at that moment. You can use this property to work with each parent the event goes through, if you want such a result.
here i would like to comment on the part of the text relating to event propagation, in particular to the book explanation on event_propagation2.fla.
The book mentioned "The target of the event dispatched to the display list will be folder0, it will propagate
through the list until it reaches folder0, and then it will bubble back up." This gave me an impression that the event went through the flow - Stage > folder_group > folder0. However, according to the Help files, useCapture is false by default and so the capture phase will not be triggered. My explanation is: since the bubbles property of the MOUSE_OVER event is true, the event actually bubbles up (instead of cascading down) and is eventually handled by the event handler assigned to folder_group. Am i right?
Gek, you're almost right.
The first thing to remember is that, for display list objects, the Capture, Target, and Bubbling phases always occur, and the event always starts at the top-most parent, propagates down to the target and then bubbles back up. In this regard, your first impression was correct, and the subtle inaccuracy is your use of the phrase "capture phase will not be triggered." The event always propagates as described (so the Capture phase is there and events are cascading down to the target), and the only question is, when is the listener function triggered?
Because the useCapture argument is false by default, the default behavior is to start paying attention when the event reaches the target, and then as it bubbles back up through the display list--hence the behavior you're witnessing in the sample file. If you set useCapture to true, your app will be actively listening for the event only on the way down to the target. To listen through the entire round trip, you need to create two copies of the same listener, one with useCapture set to true, and the other with the parameter set to false, as described above.