If you use relative paths, it might work when local, but I don’t think it will. Don’t test it with SWFLoader, it always converts relative paths to absolute which is guaranteed to be blocked when local.
On 5/25/10 3:48 PM, "Richard Rodseth" <rrods...@gmail.com> wrote: Sorry :) That seems to happen a lot with my topics. Use case 1: Customer (a sales engineer) accesses a demo that is hosted on the web like any other Flex app. This demo makes no api calls, but does need to access an XML config file that lives in a data folder beside the SWF Use case 2: Sales engineer has a copy of the entire directory (swf, wrapper html, config file) and runs it locally I think your second point confirms that to support both use cases with one version of the application, the customer would have to add a trusted location so that the app could get to the config. That may be fine, I would have to check. Since this is all read-only stuff, I would have hoped I could do it with one SWF and no user-intervention, but I imagine there are good reasons for these restrictions. On Tue, May 25, 2010 at 3:26 PM, Alex Harui <aha...@adobe.com> wrote: 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 <http://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 <http://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
