4 Replies Latest reply on May 28, 2010 9:53 AM by FTQuest

    BorderContainer ID is not accessible?

    FTQuest Level 3

      Hi,

       

      Here is the bare bone script that yields 'null':

       

      <?xml version="1.0" encoding="utf-8"?>

      <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

         xmlns:s="library://ns.adobe.com/flex/spark"

         xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600">

      <fx:Declarations>

      <!-- Place non-visual elements (e.g., services, value objects) here -->

      </fx:Declarations>

      <fx:Script>

      <![CDATA[

      private function revealID(event:MouseEvent):void

      {

      trace(event.target.id);

      }

      ]]>

      </fx:Script>

      <s:BorderContainer id="brdContainer" horizontalCenter="0" verticalCenter="0" width="200" height="200" backgroundColor="#000FF"

         click="revealID(event)"/>

      </s:Application>

       

      If I append "toString()" to the trace, it gives me classic:  TypeError: Error #1009: Cannot access a property or method of a null object reference.

       

      Thanks in advance for clarification.

      FTQuest

        • 1. Re: BorderContainer ID is not accessible?
          dave cragg Level 2

          Try using the currentTarget property on the event.

           

          trace(event.currentTarget.id);

           

          The target property points to the BorderContainer's skin, which doesn't have the id property set. This is an interesting consequence of the new Spark skinning architecture. I hadn't considered this till I saw your post.

          • 2. Re: BorderContainer ID is not accessible?
            FTQuest Level 3

            Thank you very much Dave!

            Indeed the 'currentTarget' solves the problem.

             

            Yet, I can't help to say that this behavior looks rather inconsistent.

             

            Just as an illustration, take a s:Group and put three different types of components inside it - say, mx:Image, s:Button, and s:Rect. Don't give any of those an ID. Give an ID only to the container - the  s:Group. Now, try to get the container's ID with event.target.id. Depending on which component you put inside the container you'll get 3(!) different results.

            While I'm sure there have been good reasons for such behavior - getting ID of a container depends on the content of the container -  on the surface, for unsophisticated developer it appears quite inconsistent.

             

            Could you point out where can I find the documentation that would shed more light on this?

             

            At any rate, thank you once again. Your advice helped indeed.

            FTQuest

            • 3. Re: BorderContainer ID is not accessible?
              dave cragg Level 2

              You can find an explanation here under the "About the target and currentTarget properties"

               

              http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7cdb.html

               

              I agree it can be confusing, but I don't think it is inconsistent. I tend of think of two types of objects, the one that is dispatching the event and the one that is listening for the event. When listening for a click event, the object that dispatches it is the object that you click on. So if you click on an image within a borderContainer, the image dispatches the event, and it will be the "target" of the event object. If you set a listener on the borderContainer, it will be set as the "currentTarget".

               

              The distinction can be useful. Say you have two or more borderContainers, each containing a number of objects. You can use a single handler function to listen for click events in the containers, and in that handler find out which container was clicked on and which object in the container was clicked on.

              1 person found this helpful
              • 4. Re: BorderContainer ID is not accessible?
                FTQuest Level 3

                Thanks, Dave.

                 

                FTQuest.