3 Replies Latest reply on Oct 31, 2009 4:30 PM by RickBullotta

    Hit Testing/Events on MXML Graphics/FXG elements?

    RickBullotta

      I know that I can capture a click event on a Spark Group component, but there doesn't seem to be any way to capture a mouse event or other events on individual graphics components (Ellipse, Rect, Line, etc...).  Any thoughts on how this might be done?

        • 1. Re: Hit Testing/Events on MXML Graphics/FXG elements?
          David_F57 Level 5

          Hi,

           

          If you place a graphic in a group then you use the group component to access mouse functionality. Using the mouseEnabledWhereTransparent="false" property of the group then the hit area will comply with only the non transparent areas of the group so for instance if you have a triangle or an elipse or line in the group only those graphics will give a hit area to the group.

           

          The following example does just that.

           

          David

           

           

          <?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/halo" backgroundColor="#AB4B4B" width="400" height="300">

          <fx:Declarations>

          <s:SolidColorStroke id="defaultStroke" color="{NormColor}" weight="2" alpha="0.6"/>

          <s:SolidColor id="defaultFill" color="{NormColor}" alpha="0.5"/>

          <s:SolidColor id="hiLiteFill" color="{OverColor}" alpha="0.5"/>

          <s:SolidColor id="actionFill" color="{OverColor}" alpha="0.9"/>

          </fx:Declarations>

          <fx:Script>

          <![CDATA[

          import mx.controls.Alert;

          [Bindable] private var NormColor: int = 0xFFFFFF;

          [Bindable] private var OverColor: int = 0x55FF55;

           

          private function initApp(): void

          {

          //

          }

           

          protected function group1_clickHandler(event:MouseEvent):void

          {

          Alert.show("Event","Clicked");

          }

           

           

          protected function group1_mouseOverHandler(event:MouseEvent):void

          {

          mv.fill=hiLiteFill;

          }

           

           

          protected function group1_mouseOutHandler(event:MouseEvent):void

          {

          mv.fill=defaultFill;

          }

           

           

          ]]>

          </fx:Script>

           

          <s:Group name="op_move" verticalCenter="0" horizontalCenter="0" width="36" height="36" mouseEnabledWhereTransparent="false"

          mouseOver="group1_mouseOverHandler(event)" mouseOut="group1_mouseOutHandler(event)" click="group1_clickHandler(event)" >

          <s:Path id="mv" data="M6.115,27.036L0,18l6.115-8.98v5.972c5.896,0,8.856-2.986,8.856-9.109H9.051L18,0l8.96 6,5.883

          h-5.972c0,6.123,2.986,9.109,9.059,9.109V9.02L36,18l-5.947,9.036v-6.072c-6.072,0-9.059,3.03 6-9.059,9.159h5.972L18,36

          l-9.152-5.877h6.124c0-6.123-3.062-9.159-8.856-9.159V27.036z" fill="{defaultFill}" stroke="{defaultStroke}"/>

          </s:Group>

          </s:Application>

          • 2. Re: Hit Testing/Events on MXML Graphics/FXG elements?
            RickBullotta Level 1

            Hi, David.

             

            That's very helpful.  However, it doesn't allow me to identify which graphics component (rect, ellipse, path, etc.) was clicked, does it?  We're trying to implement interactive graphics where, in many cases, the individual elements would need to be clickable.

             

            If I wrapped each individual graphic primitive in a Group, would there be any hit testing conflicts between the multiple groups (particularly if they overlapped)?

             

            I guess I can just give it a try and see what works!

             

            Thanks,

             

            Rick

            • 3. Re: Hit Testing/Events on MXML Graphics/FXG elements?
              RickBullotta Level 1

              Looks like it works fine, and hit testing seems to recognize z-order and overlapping properly (there are no transforms or masking in use, so not sure what effect those might have).