FP 9.0.16

Lewis Evans's Avatar

Lewis Evans

07 Apr, 2010 09:31 AM

I know this player sucks but our client has it installed on most of their machines.

I've just realised this and the mother is due.

I'm using the robotlegs and swift suspenders classes and not the swc but it still will not work. I can't get any traces off the swf using SOS or Flash Tracer as I dont think there is a debug player version of this build.

Anyone got any ideas or am I going to have to abandon robotlegs and rewrite my application?

Thanks in advance.


  1. Support Staff 1 Posted by Shaun Smith on 07 Apr, 2010 01:23 PM

    Shaun Smith's Avatar

    Hi Lewis,

    As far as I'm aware, Robotlegs and SwiftSuspenders should work fine for all versions of Flash Player 9 and 10.

    You mention that you are compiling against the source instead of the SWCs - have you made sure to include the necessary compiler options for SwiftSuspenders? See: http://github.com/tschneidereit/SwiftSuspenders (under Installation).

    Also, a little more info as to what's not working would be helpful. Is the app running at all? Is it just the traces that are not coming through? What do you mean by "I don't think there is a debug player version of this build"?

  2. 2 Posted by subtronic on 12 Apr, 2010 06:16 PM

    subtronic's Avatar

    Hi Shaun,

    Thanks for your reply,

    I was wrong about the debug player which I now have installed.

    I had all the right compiler arguments but it still wasn't working. I have now reverted back to using the SWC's.

    I'm using Flex Builder 3 to publish to FP9.0.16 and I get the following message prior to anything appearing on the screen:

    TypeError: Error #2007: Parameter type must be non-null. at flash.events::EventDispatcher/addEventListener() at mx.core::Container/addEventListener()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\Container.as:2052] at org.robotlegs.base::MediatorMap/org.robotlegs.base:MediatorMap::addListeners()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/base/MediatorMap.as:233] at org.robotlegs.base::ViewMapBase/set contextView()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/base/ViewMapBase.as:86] at org.robotlegs.base::ViewMapBase$iinit()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/base/ViewMapBase.as:63] at org.robotlegs.base::MediatorMap$iinit()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/base/MediatorMap.as:75] at org.robotlegs.mvcs::Context/get org.robotlegs.mvcs:Context::mediatorMap()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/mvcs/Context.as:152] at org.robotlegs.mvcs::Context/org.robotlegs.mvcs:Context::mapInjections()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/mvcs/Context.as:197] at org.robotlegs.mvcs::Context$iinit()[/Users/shaun/Documents/Development/Workspaces/GanymedeFB4/robotlegs-framework/src/org/robotlegs/mvcs/Context.as:76] at com.daredigital.barclaycard.bcdbra142::AppContext$iinit()[C:\Users\lewis\Documents\Flex Builder 3\Lewis\src\com\daredigital\barclaycard\bcdbra142\AppContext.as:11] at Lewis/Lewis::onCreationComplete()[C:\Users\lewis\Documents\Flex Builder 3\Lewis\src\Lewis.mxml:23] at Lewis/___Lewis_Application1_creationComplete()[C:\Users\lewis\Documents\Flex Builder 3\Lewis\src\Lewis.mxml:7] at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:9051] at mx.core::UIComponent/set initialized()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:1167] at mx.managers::LayoutManager/mx.managers:LayoutManager::doPhasedInstantiation()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\LayoutManager.as:698] at Function/http://adobe.com/AS3/2006/builtin::apply() at mx.core::UIComponent/mx.core:UIComponent::callLaterDispatcher2()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8460] at mx.core::UIComponent/mx.core:UIComponent::callLaterDispatcher()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8403]

    If I publish to FP10 then all is fine and I don't get this error

    I guess there is some kind of initiation sequence falure within the flash player itself.

    Does this help? If you need anything else then I can send some code over...

    I'm in the process of cutting the app out of the framework but would be much happier to find a solution to this.

    Thanks Muchly

  3. Support Staff 3 Posted by Shaun Smith on 12 Apr, 2010 06:28 PM

    Shaun Smith's Avatar

    Could you attach a sample of how you are initializing the context (in the root of your app)?

  4. Support Staff 4 Posted by Till Schneidere... on 12 Apr, 2010 06:28 PM

    Till Schneidereit's Avatar

    Hi Lewis,

    I'm afraid that's a real problem you have there: FP 9.0.16 was the
    first AS3 player to be released and it unfortunately didn't support
    the Event.ADDED_TO_STAGE event that Robotlegs uses for the
    auto-mediation feature.
    There's really only one thing you can do to still make Robotlegs (or
    any other framework with a similar auto-mediation feature) work for
    your client: Let all views that you want to support auto-mediation for
    dispatch a custom event as soon as they hit the stage (or whenever you
    want auto-mediation to be applied) and another custom event once
    they're removed from stage. Then, change the MediatorMap (specifically
    lines 233, 234 and 245, 246) to listen to those custom events.

    BTW, it's really weird that your client still has this specific
    version of the player deployed. That's a really early version of the
    player that was replaced very quickly. Meaning your client was the
    prototypical early adopter back then, but changed to being really
    conservative shortly after installing this player version.


  5. Support Staff 5 Posted by Shaun Smith on 12 Apr, 2010 06:36 PM

    Shaun Smith's Avatar

    Oh dear, thanks for clearing that up Till.

    Lewis, if you decide to go for the ADDED_TO_STAGE workaround, you could try this utility:


    Might save a bit of time.

  6. 6 Posted by subtronic on 13 Apr, 2010 02:03 PM

    subtronic's Avatar

    Tell me about the weirdness.
    They're a high street bank and its a nightmare to get them to update any of their systems, I guess it was just coincidence that they updated to that player and now we have to deal with the consequences.


    ... it works!!!

    I did a search for all instances of "ADDED_TO_STAGE" (they appear in 'MediatorMap' 'ViewMap' and also 'Context') and replaced with "ADDED". As long as I remember to remove each mediated view directly then all is good.

    Thank you both for your inventiveness.

    Next time your in London - I'll buy you both a drink!! :)


  7. 7 Posted by subtronic on 13 Apr, 2010 02:20 PM

    subtronic's Avatar

    PS. For anyone else that reads this and has the misfortune of having to target FP9.0.16. You need to change the "REMOVED_FROM_STAGE" to "REMOVED" too as this doesn't dispatch either.


  8. Support Staff 8 Posted by Till Schneidere... on 13 Apr, 2010 02:39 PM

    Till Schneidereit's Avatar

    Hi Lewis,

    I'm glad it's working! Keep in mind, though, that you have to be very
    careful when using ADDED: It's dispatched when a view is added to its
    parent, even if that parent itself is not part of the display list,
    yet. If you're not very careful with the order in which you invoke
    your addChild methods, this can lead to views not being mediated and
    to very frustrating debugging sessions.

    And thanks for the beer offer! I hope I'll be in Brighton for FOTB in
    the fall - maybe we can work out something Robotlegs-related for that.

  9. Support Staff 9 Posted by Shaun Smith on 13 Apr, 2010 03:37 PM

    Shaun Smith's Avatar

    Hey Lewis,

    This is good news, but as Till mentioned, ADDED can cause some funky, hard to diagnose, behavior. If you plan to stick with this work-around, I think it's quite important that you document it loudly - so that anyone who has to do maintenance, or add features, down the line is aware of it (even if that person is you).

    To be honest, I still think that the LazyMediator util might be a better solution. It's pretty easy/quick to implement and actually results in better performance for the app. Also, you can use it in your app without editing the RL framework source; editing framework code will be problematic when it comes time to upgrade to a newer version of RL - you'll need to remember to modify those same files.

    Anyhow, just my 2 cents :)

  10. 10 Posted by subtronic on 14 Apr, 2010 03:49 PM

    subtronic's Avatar

    Hey Guys,

    You are right I do get some anomalies by doing it this way but if I use the LazyMediator I get the same error as with using the MediatorMap but in ViewMap this time even if I comment out all the code in my MainContext startup block. Also it still has a problem with "REMOVED_FROM_STAGE" as this doesn't fire either.

    Any ideas?


  11. Support Staff 11 Posted by Shaun Smith on 14 Apr, 2010 04:42 PM

    Shaun Smith's Avatar

    Damn, I totally forgot that the LazyMediator util relies on ADDED_TO_STAGE internally (for some reason I thought it didn't):


    What I find crazy is that the code compiles in the first place! If the ADDED_TO_STAGE constant is not defined for your target the compiler should throw a compile-time error instead of waiting until runtime to tell you that ADDED_TO_STAGE is null.

    In all honesty, I'm starting to think that you'll need to mediate your components manually. How many mediators do you have in your app? Worst case scenario: you'll have to edit out all references to ADDED_TO_STAGE, turn off auto-mediation (by setting enabled to false on the MediatorMap), and call mediatorMap.createMediator(view) for your view components manually.

    I'm really sorry about all this - I was unaware that there was a version of the Flash Player that didn't support ADDED_TO_STAGE.

  12. Support Staff 12 Posted by Till Schneidere... on 14 Apr, 2010 04:58 PM

    Till Schneidereit's Avatar

    What I'd do is this:
    Let all views you want to mediate extend a base class.
    In this base class, use an ENTER_FRAME listener to check if the
    "stage" property is defined.
    Once that's the case, dispatch a custom event (or, better yet: simply
    dispatch "addedToStage", then you don't need to change Robotlegs at
    Then switch to another ENTER_FRAME listener to check for "stage"
    becoming null, upon which you dispatch a custom event or
    At this point your view isn't on the stage anymore, so the event won't
    be caught by the MediatorMap. Because of that, your Mediator will have
    to listen for it and manually remove itself from the MediatorMap by
    invoking "mediatorMap.unmapView(view)".

    I know it all sounds a little complicated, but as long as you can let
    your views extend a base class, it shouldn't be too bad.

  13. Support Staff 13 Posted by Shaun Smith on 14 Apr, 2010 05:07 PM

    Shaun Smith's Avatar

    That sounds like a good approach. There is still the issue of Event.ADDED_TO_STAGE evaluating to null though (as the original error message indicates):

    TypeError: Error #2007: Parameter type must be non-null. at flash.events::EventDispatcher/addEventListener()

  14. Support Staff 14 Posted by Till Schneidere... on 14 Apr, 2010 05:14 PM

    Till Schneidereit's Avatar

    That's why I'd use the actual string: "addedToStage".

    I guess what happens with Event.ADDED_TO_STAGE is that the compiler
    adds a lookup of the property "ADDED_TO_STAGE" on the object "Event".
    Since Event is a class and classes are dynamic, the Flash Player
    simply returns undefined instead of throwing an exception, as, in
    fact, Event.ADDED_TO_STAGE is undefined in FP 9.0.16.

  15. Support Staff 15 Posted by Shaun Smith on 14 Apr, 2010 05:22 PM

    Shaun Smith's Avatar

    Yeh, but what I meant was that the RL source is going to fail at every point where Event.ADDED_TO_STAGE is used. Dispatching the string "addedToStage" is fine, it's where the framework listeners are wired up that errors will be thrown.

  16. Support Staff 16 Posted by Till Schneidere... on 14 Apr, 2010 05:34 PM

    Till Schneidereit's Avatar

    Aah, of course. Dammit, hadn't thought of that. Ok, so Lewis: You'll
    definitely have to change your Robotlegs code. I guess changing every
    instance of "Event.ADDED_TO_STAGE"/ "REMOVED_FROM_STAGE" to
    "addedToStage"/ "removedFromStage" and then following the steps
    outlined above should do the trick.

  17. 17 Posted by Jason Dias on 14 Apr, 2010 07:23 PM

    Jason Dias's Avatar

    Just a thought, what we had to do to get WAMU to upgrade, was show them the penetration rate of the new player http://www.adobe.com/products/player_census/flashplayer/version_pen... and make them aware of the security issues with that particular player version, header injection, etc

    Maybe if you made them aware of that they would upgrade?

    Anyways good luck ether way.

  18. 18 Posted by lewisevans on 06 May, 2010 05:21 PM

    lewisevans's Avatar

    Hi Guys,

    Back on this project again managed to sort this out thanks to all your help.

    I changed all Event.ADDED_TO_STAGE instances to "addedToStage" and all "Event.REMOVED_FROM_STAGE" instances to "removedFromStage".

    I also did as Till mentioned and added a class to my AbstractView:

    package org.robotlegs.utilities.patch
    import flash.display.DisplayObject;
    import flash.events.Event;
     * @author [email blocked]
    public class StageEventListener
        private var view:DisplayObject;
        private var alreadyAdded:Boolean = false;
        public function StageEventListener(target:DisplayObject)
            view = target;
            view.addEventListener(Event.ENTER_FRAME, checkStage);
        private function checkStage(e:Event):void {
            if(view.stage && !alreadyAdded) {
                alreadyAdded = true;
                view.dispatchEvent(new Event("addedToStage"));
            } else if (!view.stage && alreadyAdded) {
                alreadyAdded = false;
                view.dispatchEvent(new Event("removedFromStage"));

    Then in my mediator listened for the removed event but unmapView didn't work so I used mediatorMap.removeMediator(this);

    All works fine for me but can you imagine any problems with this?



  19. Support Staff 19 Posted by Till Schneidere... on 06 May, 2010 05:31 PM

    Till Schneidereit's Avatar

    I think that's as good as it can get for automated view mediation in FP 9.0.16

  20. Support Staff 20 Posted by Shaun Smith on 06 May, 2010 05:34 PM

    Shaun Smith's Avatar

    Surely those events need to bubble?

    view.dispatchEvent(new Event("addedToStage", true));

  21. 21 Posted by subtronic on 07 May, 2010 02:53 PM

    subtronic's Avatar

    Er, mine aren't.

    Doesn't the framework actually listen to the view directly for ADDED_TO_STAGE events when you addListeners() in MediatorMap?

    This approach does work its just a little messy. Is there not a way I could add something to the MediatorMap to listen for the "removedFromStage" event sent from the view automatically as opposed to adding view.addEventListener("removedFromStage", unmapView); to each in my mediators?

    In fact shouldn't addListeners() automatically add both directly to the view anyway. Would making the events bubble sort this out?

  22. Stray closed this discussion on 10 Feb, 2011 05:26 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac