Connoisseur of Technology

Adobe Flex events generated by your own custom components can be tricky to debug. Here are some guidelines that I have found helpful to make sure that events generated by custom components.

  1. Define custom events instead of using vanilla flash.events.Event; this will allow you to be sure that events are routed exactly where they are intended.
    [Event(name="deleteClicked", type="com.bigco.project1.CustomEvent1")]
  2. The event name used in the Event declaration above causes a new attribute of that name to be created for your custom component. The event handler can be passed an event; if you provide a parameter (called event by convention), that parameter will be of the type you specified in the Event declaration above.
    1. Here is an example:
      <ns:myComponent id='id1' deleteClicked='eventHandler(event)'/>
    2. Another way of establishing an event handler is to write the equivalent ActionScript code. This is necessary if you want to set up more than one listener to a specific event:
      id1.addEventListener(CustomEvent1.CUSTOM_EVENT, eventHandler);
  3. The event handler referenced above might be declared with the following signature:
    private function eventHandler(event:CustomEvent1):void { /* method body here */ }
  4. Include a public static String constant in the custom event so you don’t make spelling mistakes when referring to it. Here is an example custom event definition, in which the String constant is called CUSTOM_EVENT:
    package com.bigco.project1 {
      import flash.events.Event;
      public static const CUSTOM_EVENT:String = 'CustomEvent1';
      public class CustomEvent1 extends Event {
        internal var _param1:String;
        public function CustomEvent1(param1:String, bubbles:Boolean=false,
                                     cancelable:Boolean=false) {
          super(ITEM_DELETE_EVENT, bubbles, cancelable);
          _param1 = param1;
        }
      }
    
      override public function clone():Event {
        return new CustomEvent1(_value, bubbles, cancelable);
      }
    }
  5. Custom components are likely to consist of one or more widgets nestled within a container. If events are dispatched from the outermost container of the custom component, event bubbling is often not required. On the other hand, the only way for an event generated from a widget deep inside a custom component to be propagated outside of the custom component, is to enable bubbling. This brings up several issues:
    1. Flex events are not broadcast to all components. By default, Flex events are only sent from the dispatching component to its parent. If you enable event bubbling by passing true as the second parameter to dispatchEvent(), the event will propagate towards the application root container (<mx:Application/> or <mx:WindowedApplication/>) until the event is handled.
    2. If you call dispatchEvent() without specifying an object, the ‘this’ object will be the source of the event. If you are in doubt which object ‘this’ pertains to in your event handler, you might want to examine the widget type and/or id at runtime (use a debugger or trace statement.) For the case where a nested widget dispatches the event, you should ensure that the widget’s parent generates the event. This example disables event bubbling because only one parameter is passed to dispatchEvent:
      parent.dispatchEvent(CustomEvent1.CUSTOM_EVENT);

      If the component that generates the event is more deeply nested in your custom component (perhaps inside a second HBox or VBox), you will need to reach further up the component tree before dispatching, like this:
      parent.parent.dispatchEvent(CustomEvent1.CUSTOM_EVENT);

    3. Using a custom event will ensure that dispatchEvent and the event listener will both reference the same type of event. If you don’t do this, mismatched event types will not trigger the desired event handler, or perhaps not even trigger any event handler.
    4. Most of the event handling documentation I have read assumes that the dispatching widget is a child of the widget that must handle the event. If the consumer of the event is elsewhere in the widget tree (aunt, uncle, niece, nephew or distant relative?) you may want to define an event listener using parentApplication. The following example sets a listener at the Flex component called id2:
      parentApplication.id2.addEventListener(CustomEvent1.CUSTOM_EVENT, eventHandler);
Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • Print this article!
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis

Comments

2 Responses to “Debugging Flex Events Generated by Custom Components”

  1. stevecrozz on February 16th, 2009 10:21 pm

    I just wanted to thank you for this. I was struggling with my own custom events for a while until I found this page and realized my event handlers were wrong. They do have to accept the incoming event as an argument. When I didn’t define them that way, they would silently fail to do their job instead of issuing a warning. What a pain in the neck!

  2. Sending custom events between components « Price Talk on December 16th, 2009 11:16 pm

    [...] found this pretty straightforward easy to understand article here, that explains that the event never travel across from component to component ( up and down the [...]

Leave a Reply

You must be logged in to post a comment.