I wish it was that easy :-P.. Nope, we don't set a preloader of anykind.. I even did a search for "preload" in my project to see if maybe the libs we are using do, but nope.. the source to the libs we are using don't do anything to the preloader too.
So I've been walking through the code and this is what seems to be happening..
1) the app decompresses once (
[SWF] C:\Perforce\DatranDisplay\Display_AdPlanner\DisplayFlex\DMAR_Flex\bin-debug\DMAR_Flex.swf - 5,150,945 bytes after decompression)
2) SystemManager.initHandler is called and the isStageRoot = true..
3) the spark preloader is found and used just fine. (line 1858 of SystemManager.initialize)
4) it goes on just fine (not failing at line 253 of preloader.Initialize where it tries to set the displayClass = new displayClassName())
4) The app is decompressed a second time?(
[SWF] C:\Perforce\DatranDisplay\Display_AdPlanner\DisplayFlex\DMAR_Flex\bin-debug\DMAR_Flex.swf - 562,251 bytes after decompression)
5) SystemManager.initHandler is called a second time but this time isStageRoot = false
6) no DisplayClassName is found in SystemManager.initialize so null gets passed into preloader.Initialize and then it blows up at displayClass = new displayClassName() (because this time displayClassName = null)..
Anyways, I am all ears.. I'll keep debugging, but as of yet I have yet to hit a line of my code before this explosion happens...
It is a bit confusing, but the Application's preloader attribute defines a
IPreloaderDisplay which becomes the displayClassName for the Preloader
You may see additional decompressions as RSLs are loaded. We don't get
enough data to display the RSL names.
The default IPreloaderDisplay is one of the mx.preloader classes like
DownloadProgressBar or SparkDownloadProgressBar. You can run a link-report
to see if they are somehow not linked into the SWF. You can also use -keep
and see what is in the ***SystemManager-generated.as file. There should be
a reference to the IPreloaderDisplay in that generated file.
Ok so I did a -keep and checked my ***SystemManager-generated.as the funciton info() was setting the sparkdownload progress just fine
and it was importing both ths spark and mx progress bars
then I checked my link report.. and sure enough the spark preloader was there
<script name="C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\4.0.0\frameworks\libs\framework.swc(mx.preloaders:SparkDownloadProgressBar)" mod="1263586859699" size="13103" optimizedsize="6977">
as was the mx.preloaders.preloader
<script name="C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\4.0.0\frameworks\libs\framework.swc(mx.preloaders:Preloader)" mod="1262975731760" size="6770" optimizedsize="4160">
as was the IPreloaderDisplay
<script name="C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\4.0.0\frameworks\libs\framework.swc(mx.preloaders:IPreloaderDisplay)" mod="1262975731869" size="2113" optimizedsize="508">
what wasn't in my link report was the mx.preloaders.DownloadProgressBar, but it was probably optmized out because it isn't actually ever called...
And I can tell that info() is the one being called the first time through (when the first RSL decompression happens), so that's not it..
Is there a way to figure out what tha second RSL decompression is? It seems to me thats where the issue is.. (from what it looks like (based on width and hight numbers that the first decompression is my application (having my apps height and width) the second decomression is my object tag in my browser (because it has the height and width numbers I am setting there.. (which are different because I am trying to use the scaleMode to make the app scale to fit different sizes)..
Oh and if I haven't said it yet, Thank you very much for your guidence on this.. Its a real headscratcher for me.
Finally found the issue.. Along with the Libraries I was using, there was a swf resource that was being used (a spinner) it was a flex app compiled on 3.x and then embedded as a resource (rathre than as a library).. When that 3.x compiled swf tried to load thats what would cause the failure.. Simply opening the project, changing the mx namespace to the newo 2009 namespace and recompiling fixed the problem. (once I found out about it..) So it looks like there is a general incompatability between 3.x libraries (and resources) and 4.x projects.. Has this incompatability been documented anywhere so that others are aware that porting a project, will include not juts the project, but all associated libraries and possibly all associated resources as well? Thanks for your help.. your hints were the clues I needed to figure this out. Josh Handel