I got lost trying to follow this topic. Whether it is browser or standalone shouldn’t matter. What matters is the url of the SWF (file:// or http://), the trust file settings on the computer, the use-network flag, and how you access the external resources.
If you build a SWF to run locally then it cannot access the network. If you build a SWF to access the network, it cannot access the local files unless trusted. Even if trusted, you may run into issues using certain file paths. Be sure to use relative paths to subfolders of the trusted folder. On 5/25/10 2:42 PM, "Richard Rodseth" <rrods...@gmail.com> wrote: Thanks. That sounds like a "no" for supporting my two use cases, unless the customer adds a trusted location or opens the SWF in the standalone player. On Tue, May 25, 2010 at 12:45 PM, Oleg Sivokon <olegsivo...@gmail.com> wrote: OK, it's like this: SWF launched in standalone player can interact with the system AND load remote content, just like the browser can do the same thing. SWF launched in browser plugin can only access permitted folders on your hard disc. To allow access to the folder you should either use the web interface (see my previous link), or read from the link Ami posted and try to figure out how to do that on Mac (you are not required to use web interface to establish local trust relationships between SWF and specific locations in file system, it's just that, I simply don't know how to do that on Mac...) There's yet another option for launching a SWF - that's how I usually do that - from the local HTTP server, in such case it acts more like as if it was deployed to the actual server and all the following rules apply. I would definitely recommend the later way of debugging as it is the most similar to the live situation. The loading of content other than SWF into another SWF is governed by policy files aka crossdomain.xml. You need these files if you are loading content from domains other than SWF origin. The loading of other SWFs by SWF is governed by two things: ApplicationDomain provided to the Loader when loading SWF with LoaderContext - by default it won't allow crosscripting. Security.allowDomain() doesn't define how classes are loaded into application domain, however, should prevent security errors related to crosscripting. Well, yes, it is complicated... -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
