Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

LoaderMax.defaultAuditSize = false causes load to fail

Recommended Posts

hey guys


Do you know of any reason why setting LoaderMax.defaultAuditSize = false; would cause the load to become unstable or simply not happen?


seems to be happening in my swf




Link to comment
Share on other sites

You're saying if LoaderMax.defaultAuditSize is true, things work fine for you but if you change it to false, they break? I can't imagine how/why that'd happen, no, but I would LOVE to see a simple example FLA that I could publish to see the issue. Please don't post your production files with lots of extra code - just a super simple FLA with only the essential code (and support files) would be super. I'm sure we can get it figured out.

Link to comment
Share on other sites

hey jack


thanks for the response.


Unfortunately the flash is part of a much large cq5 content managed system which has several dynamically created files that are being loaded.


UPDATE: i just discovered that if i remove all of the estimatedBytes that it fixes the problem when defaultAuditSize = false.


thanks anyway dude - we all love your stuff



Link to comment
Share on other sites

  • 4 weeks later...

Hello, Jack.

Actually, I have just the same issue. Unfortunately, I can not post code here, because this is closed project, but I will try to explain all in details. I have some loading factory, which uses LoaderMax and ImageLoader as items of LoaderMax queue. Everything is pretty easy - I have one loading queue (Loadermax), and adding ImageLoader instances into it. First of all, from what I understand noCache property is set to true for ImageLoader by default, which is a little bit strange at least for me, because you typically want images to be cached by the browser and not reloaded each time. In my case, it caused each image to load 2 times (I am really not sure why, this is something I see in FireBug, this double loading, and I definitely adding only one instance of particular ImageLoader per one image. Maybe, it interfere somehow with the fact, that i do no have direct urls of images - meaning that the urls does not represent direct location of image on the server. The urls are dynamic, consisting of base url and image id, and the server returns correct image based on the id). Anyway, setting noCache property to false to each ImageLoader instance does not remove gsCacheBuster part from the final url. The final url also contains purpose=audit part, and this is related to auditSize property of the LoaderMax. Setting defaultAuditSize static property of LoaderMax to false removes both gsCacheBuster and purpose=audit parts from final url, making this url just what I wanted. However, this caused another issues. For some reasons, crossdomain policy file is not loaded anymore (again, this can be "fixed" just by not setting defaultAuditSize to false), and the rawContent property of the ImageLoder becomes of type Loader instead of Bitmap. Also, not sure whether this may be important or not, the images are loaded from https, not http. But anyway, it's a little bit weird that setting or not setting defaultAuditSize influence all this stuff.



Link to comment
Share on other sites

I have just found the answer on your forum, why setting noCache = false will not remove gsCacheBuster from url


However, I think it's better to include this info into docs.

Still, I have that main issue - setting auditSize to false will prevent from loading crossdomain file, thus rawContent of the ImageLoade will be of type Loader

Link to comment
Share on other sites

OK, I have found and fixed the issue.

When setting auditSize to false, you also need to explicitly set LoaderContext to check policy file. So, adding following code will fix the issue.

var context:LoaderContext = new LoaderContext();
           context.checkPolicyFile = true;
           context.securityDomain = SecurityDomain.currentDomain;
           LoaderMax.defaultContext = context;


Jack, I still believe it will be great to put all this info into the docs. Personally, i feel that it's very frustrating when you have noCache property, which is pretty self-explanatory, you set it to false, and it change nothing. Putting the description of such possible case (that you may need to set auditSize to false and define LoaderContext) may save some time for others. Having this info inside docs is nice, because I believe most of the people tries to find the answer there first, and only after that go to forum.


Kind regards,


Link to comment
Share on other sites

Hmmm...I'm confused - the default LoaderContext you defined is pretty much exactly what LoaderMax uses by default anyway. Feel free to look at the source (in DisplayObjectLoader's _load() method). It sets the loadPolicyFile to true anyway. I'm baffled as to why opening a URLStream first to the URL (which is all auditSize:true does) and closing it immediately would somehow cause the policy file to load whereas not opening that URLStream (and yet using a LoaderContext with loadPolicyFile set to true) wouldn't load the policy file. See what I mean? (that is what you're saying, right?)


Are you running the app locally (which would force a different SecurityDomain) or something? It's so much more difficult to troubleshoot without having a solid (and simple) example that I can publish, add trace() statements to, etc.


And you are using the latest version of LoaderMax, right?

Link to comment
Share on other sites

I will try to make a sample code. Because it interesting to find real reasons of such behavior, even if there is some solution how to fix it.

Link to comment
Share on other sites

OK, some things first:

1) I am testing locally (on local server, not just running the app from some folder), and the issue occurs just like described.

2) The issue does not occur if running the same app from remote server

3) Still, I am not sure why setting this static property will make the app work or not work when running locally

4) following code is flex based, but guess you can easily make it pure flash if you need. Just uncomment corresponding lines for testing.

5) Why does "trace(queue.auditedSize)" returns true even when defaultAuditSize is set to false?

6) i did some test - put the line break inside the _load function of DisplayObjectLoader, trying to find what is the actual context supplied to the loader. It was null in both cases - when defaultAuditSize was set to false, or was not set at all.

7) The project was started several month ago, so I am using the version which I had that time. The LoaderMax version is 1.831


Here is the code


              xmlns:local="*" creationComplete="application1_creationCompleteHandler(event)">

Link to comment
Share on other sites

When running a file locally, Flash will throw errors if you use a LoaderContext with the current SecurityDomain. So LoaderMax will automatically sense if you're running locally and use a null LoaderContext (which basically tells the Loader to use its default settings). That explains why _context was null for you (you're running locally).


Have you tried using Security.loadPolicyFile()? http://help.adobe.com/en_US/FlashPlatfo ... olicyFile() I'd be curious to know if that solves things for you.


The auditedSize property serves as a flag that indicates whether or not the loader has figured out its size or if it requires auditing. When LoaderMax starts loading its queue, it analyzes each child loader and if it finds one that has a false auditedSize and the LoaderMax doesn't have that feature disabled, it knows that it needs to do an audit. If, however, you provide an estimatedBytes or if you turn auditSize off, that'll set auditedSize to true which basically says "don't pester me for audits - I don't need any".

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.