FP 9.0.16
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.
Lewis
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | 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
Support Staff 1 Posted by Shaun Smith on 07 Apr, 2010 01:23 PM
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 Posted by subtronic on 12 Apr, 2010 06:16 PM
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
Lewis
Support Staff 3 Posted by Shaun Smith on 12 Apr, 2010 06:28 PM
Could you attach a sample of how you are initializing the context (in the root of your app)?
Support Staff 4 Posted by Till Schneidere... on 12 Apr, 2010 06:28 PM
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.
cheers,
till
Support Staff 5 Posted by Shaun Smith on 12 Apr, 2010 06:36 PM
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:
http://github.com/eidiot/robotlegs-utilities-LazyMediator
Might save a bit of time.
6 Posted by subtronic on 13 Apr, 2010 02:03 PM
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.
Anyway...
... 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!! :)
Lewis
7 Posted by subtronic on 13 Apr, 2010 02:20 PM
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.
Cheers
Lewis
Support Staff 8 Posted by Till Schneidere... on 13 Apr, 2010 02:39 PM
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.
Support Staff 9 Posted by Shaun Smith on 13 Apr, 2010 03:37 PM
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 Posted by subtronic on 14 Apr, 2010 03:49 PM
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?
Lewis
Support Staff 11 Posted by Shaun Smith on 14 Apr, 2010 04:42 PM
Damn, I totally forgot that the LazyMediator util relies on ADDED_TO_STAGE internally (for some reason I thought it didn't):
http://github.com/eidiot/robotlegs-utilities-LazyMediator/blob/mast...
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.
Support Staff 12 Posted by Till Schneidere... on 14 Apr, 2010 04:58 PM
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
all).
Then switch to another ENTER_FRAME listener to check for "stage"
becoming null, upon which you dispatch a custom event or
"removedFromStage".
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.
Support Staff 13 Posted by Shaun Smith on 14 Apr, 2010 05:07 PM
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()
Support Staff 14 Posted by Till Schneidere... on 14 Apr, 2010 05:14 PM
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.
Support Staff 15 Posted by Shaun Smith on 14 Apr, 2010 05:22 PM
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.
Support Staff 16 Posted by Till Schneidere... on 14 Apr, 2010 05:34 PM
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 Posted by Jason Dias on 14 Apr, 2010 07:23 PM
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 Posted by lewisevans on 06 May, 2010 05:21 PM
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:
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?
Thanks
Lewis
Support Staff 19 Posted by Till Schneidere... on 06 May, 2010 05:31 PM
I think that's as good as it can get for automated view mediation in FP 9.0.16
Support Staff 20 Posted by Shaun Smith on 06 May, 2010 05:34 PM
Surely those events need to bubble?
view.dispatchEvent(new Event("addedToStage", true));
21 Posted by subtronic on 07 May, 2010 02:53 PM
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?Stray closed this discussion on 10 Feb, 2011 05:26 PM.