7 Replies Latest reply on Oct 28, 2009 8:32 AM by RickBullotta

    FXG/MXML Graphics Issues

    RickBullotta Level 1

      OK, thanks to Ely I've been talked down from the ledge and am back to doing cool things with MXML graphics...


      I've come across two issues that I'd like to discuss and see if there are any workarounds or if I've encountered an issue/bug.


      The first one relates to an issue I've encountered dynamically adding spark graphics primitives in ActionScript.  I can add them successful to the elements collection of a group, and they display just fine.  I set an "id" value before I add them.  However, there does not appear to be any way to access them by "id", either from the top level Application object or anywhere else.  Graphic elements added statically in the original MXML, of course, work fine and can be accessed using this["theID"], as with any other MXML object.


      The second relates to adding blur and other effects to dynamically created graphics elements.  For the life of me, I just can't get them to display.  They seem to be added successfully (I create them and add them to the filters collection).


      I'm using the Beta 2 release of Flash Builder and the Flex 4 SDK.


      Thanks in advance for any insights.

        • 1. Re: FXG/MXML Graphics Issues
          Ely Greenfield

          Rick --  flex doesn't support any sort of dynamic getElementById() 

          lookup the way HTML does. You'll have to write that yourself, using 



          Regarding filters...you'll seend to submit a bug, there's no reason 

          why that shouldn't work (could be pilot error of course



          • 2. Re: FXG/MXML Graphics Issues
            RickBullotta Level 1

            Hi, Ely.


            I was under the impression that with most MXML containers, you can use this[id] to get a reference to the object dynamically, such as this['myThing'], and of course getChildByName('myThing').  This works with statically or dynamically created display objects.  Except with Spark.  :-(


            I had assumed that such a mechanism would work with Spark, but it appears not - as a side effect of the child <-> element different in terms of managing and accessing the container children.  Out of curiosity, do you know why didn't Spark get an "getElementByName()" method as an analog to MX's getChildByName()?  I assume it is due to the underlying collection type being used to manage the display list.  Just curious.


            The issue with filters seems to apply to any filters added at runtime - they never seem to render.  I'll see if it is pilot error, and if not, I'll report a bug.





            • 3. Re: FXG/MXML Graphics Issues
              CoreyRLucier Adobe Employee

              That should only work with objects that were provided an id at compile 

              time, as the compiler will ensure a slot (property) on the owning 

              document corresponding to that declaration.



              • 4. Re: FXG/MXML Graphics Issues
                Flex harUI Adobe Employee

                And getChildByName does not work with IDs


                Alex Harui

                Flex SDK Developer

                Adobe Systems Inc.

                Blog: http://blogs.adobe.com/aharui

                • 5. Re: FXG/MXML Graphics Issues
                  Ely Greenfield Level 1

                  this['myThing'] only works if myThing was statically declared in the 

                  MXML document, I believe.

                  getElementByName -- I think it's just not implemented out of a belief 

                  that there wasn't a general need for it.  It's something that could be 

                  added to containers, if the community wants it.



                  • 6. Re: FXG/MXML Graphics Issues
                    RickBullotta Level 1



                    No worries.  It's easy enough just to create another object to hold the references to the dynamically created objects, keyed by name.  That said, it would be very useful to have the ability to use "getElementByID()" on any container to grab a reference to any statically or dynamically created component by its id.   I suppose the companion capability is to have the Application (or other appropriate container) include dynamically created components in that list.  There are definitely workarounds today, though.


                    We (and quite a few others, I'd think) have been dynamically generating UI's at runtime using ActionScript, and this capability is really useful for wiring together events, data binding, setting/getting properties on selection events, and so on.  We'd used it in Flex 3 to link UI components (and their underlying HTTPService data providers) together "on the fly", and it works fine with a little bit of reflection and invocation magic.  We'll just extend our custom classes to maintain a list of dynamically added Spark graphics primitives so that we can animate them in a similar manner.


                    If you're wondering, the main reason we have to do the dynamic UI creation is because we want to provide a higher level UI authoring environment to the end user, rather than Flash Builder/Flex Builder, with more of a drag-and-drop, wire things together sort of metaphor.  It generates "pseudo-MXML" which then gets processed at runtime.  We had explored dynamic generation of "real" MXML and/or inline compilation, but we needed a solution that would run on .NET platforms as well as Java/JSP platforms.  I'm guessing there's no plan to provide programmatic or inline MXML compilation for .NET.


                    I think we have a workable solution for now, though.





                    • 7. Re: FXG/MXML Graphics Issues
                      RickBullotta Level 1

                      Here's an update on the dynamic assignment of filters issue:  You cannot add or remove individual filters using ActionScript - you can only replace the entire filters collection en masse.  If you do so, the display object will render properly.  However, manipulating the filters array by adding or removing filters will not work.  Let's consider it a "known feature"...