public function creationComplete(event:FlexEvent):void
var loader:Loader = new Loader();
private function loaderComplete(event:Event):void
var loaderinfo:LoaderInfo = event.target as LoaderInfo;
var loader:Loader = new Loader();
var loaderContext:LoaderContext = new LoaderContext();
loaderContext.allowCodeImport = true;
private function onLoadComplete(event:Event):void
var displayObject:DisplayObject = event.target as DisplayObject;
var ui:UIComponent = new UIComponent();
Can you load other swfs ok? Is it just this swf that you are having a problem loading?
I believe the pattern is to use URLLoader to get the SWF as a byteArray
before loading into a Loader with loadBytes
Is the error followed by a stack trace? Please post the entire stack traces
Hello. I got almost the same problem. Althought I'm not sure the guy above is using AIR as a frontend.
So my situation is as follows: I got AIR app where I load swf from remote URL.
The load is done by URLLoader (BINARY mode) and then loadBytes() on Loader, where I pass LoaderContext like:
var lc = new LoaderContext(false, ApplicationDomain.currentDomain);
lc.allowLoadBytesCodeExecution = true;
So later on when the ASync load is done, as the constructor of the loaded swf file is being called an error is thrown:
SecurityError: Error #3207: Application-sandbox content cannot access this feature.
This is pdf2swf - e.g. MainTimeline is a generated class on which I don't have much control. I mean I can't remove the problematic line with Security.allowDomain() stuff.
Any useful ideas would be good
That SWF was not meant to be loaded via LoadBytes. You will have to load it
Well.. no, that would not be possible. I need the bytes to be decrypted before they parse by the Loader. How is that gonna happend if I do Loader.load(URLReq)? Althou the application must be able to work offline with offline files. Must I decrypt the files once on the user's HDD (and expose all the ©d data) or I there is a way to load and run that particular swf with these Security.allowDomain(...) lines? The last variant is to replace bytecode on the server-side but that's just non-sense level
Althou it will work
Some swfs are simply not designed to be loaded by other SWFs.
Thanks for your response, but my questions is way different from what you are talking about. Let me put it this way: is there a way to tell the Loader to ignore or workout somehow the System.allowDomain() statement or there is no such way?!
Do you think Adobe add security features to their player and development systems, only to tell you how to bypass them?
You are right... But the way I see it is that I'll do my thing one way or another and that error will only make my work harder. Althou I don't know a security feature of adobe that does something other than pointless.... Like it was said: "A user with root can't do sh!t. A root with user can do anything". So instead of something useful or constructive adobe's security is only pain in the 455, feature limiting bullsh!t. And that's not just my oppinion but I don't see a reason not to allow this particular action?! WHY SHOULD I NOT BE ABLE TO LOAD SWF IN WHICH IS SAID: ALLOW DOMAIN "*"????? WTF? How comes that this is called security? This should be called bullshurity... lameability... whatever
Just to clear things up for the next guys with that kind of problems: I embedded the swf (viewer) which loads the local swf (document) in the AIR Application as "application/octet-stream" and load it as ByteArray. This way the viewer.swf loads successfully and the document.swf works fine.
There is only one problem... which is as stupid as possible but to be clear: I got TileList and the items there got images like thumbnails. Everything works fine, displays fine, except at the moment when I try to drag the item. The DragManager tries to draw the dragged object into a BitmapData (for the dragging fx) which throws a SecurityError:
*** Security Sandbox Violation ***
SecurityDomain 'app-storage:/43.img' tried to access incompatible context 'app:/PStore.swf'
So.. that's totally insane - it's just a fsckn JPEG! What harm could possibly do to your computer a damn JPEG loaded by Loader - JPEG - not SWF?! To stop code execution between app-storage: and app: is another stupid idea... Now you tell me if this is not a good bullsh!t story
And still this opens many questions, like: why would Adobe limit the code execution that stupid? Why? Preventing what? Whatever they prevent can be workarounded so... what's the point anyway?! I really don't get it? These stuff stops lamers to do something harmful. Great! But the lamers are not threat. The non-lamers should be considered as dangerous. Anyway, as the time goes Adobe became non-nice corporation and some day they should pay a price for that. I'm sure