I actually have experienced the reverse of this issue. Flash caches the dynamic content so hard that I have reverted to using no_cache meta tags in my HTML. Not to OT the topic, but are meta tags the best way to prevent this? I have even though of adding a variable at the end of my dynamic urls with a date element so flash would constantly think its a new XML doc to load everytime.
Nathan Mynarcik Interactive Web Developer [email protected] 254.749.2525 www.mynarcik.com -----Original Message----- From: [email protected] Date: Wed, 10 Mar 2010 13:46:08 To: Flash Coders List<[email protected]> Subject: Re: [Flashcoders] Apparently Doesn't Check Cache Every request for a file will go back to the server at some level. For example, despite the fact that have a file "preloaded' into cache when another request is made for the file it will look at the cache then send a request to the server to see if the file has changed or whether the file in cache is valid to use. If the server returns "use file from cache" then it will use the cached file otherwise it will load the "revised" version from the server. First questions would then be what is the header returned as part of the original file request. Is it no-cache or does it set a very short expiry? Are the url's exactly identical or is there any kind of query string associated with the url of one request but not the other? This might be walking on thin ice here, but can you see the file in the browser's cache? Back in the day, when I was doing Director development, there was a period of time that elapsed from when "Shockwave" loaded the file and the time that it went into the browser's cache. The file was always available within the Shockwave environment but it was immediately visible in the browser's cache. Don't know if a similar situation arises with Flash where the content is loaded but hasn't yet been written into the browser's cache. I'd honestly start out by using something like Internet Explorer where you can easily browse the cached files -> blow away the cache and then load your swf preloader app. See if the files are in cache. If they are cool, note the URL associated with them. Then I'd go back and clear the cache again and re-run the app with the new window code in place. I'd run it through to completion and see if there are two copies of said image in cache one from the swf preloader and the other from the new window. If so it would imply that they must be seeing slightly different urls. If not then I'd be looking for no cache headers. Concurrent to this I'd be using something like Fiddler (IE), Charles or Tamper Data or similar app that will allow you to see the requests and the responses and be able to examine the headers and check for no-cache or very short expiry on the headers. Theoretically what you are doing should work, I can't see how placing the image on stage would make any difference. Everything is always a possibility but using a test strategy that stepwise verifies what is getting written into cache and what the request are for the files is a good first step in eliminating many issues. Sincerely Mark R. Jonkman _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
