LoaderMax onError in LoaderItem.as code order issue

[Chris7777]

Hi,

 

I have noticed when outputting e.text from an onError function callback the information displayed refers to the alternateURL not the actual URL that is error'ing.

 

Example:

 

var loader:SWFLoader = new SWFLoader("primary_child.swf", {
name:"mainSWF", 
container:this,
onFail:onFail,
onError:onError,
alternateURL:"alternate_child.swf"	
});

//begin loading
loader.load();

function onFail(e:LoaderEvent):void 
{
trace("Page Load Fail:: Details: " + e.text + " " + e.target); 
}

function onError(e:LoaderEvent):void 
{
trace("Page Load Error:: Details: " + e.text + " " + e.target); 
trace("Attempting to load alternate url");	
}

 

And the error output is:

 

----
Loading error on SWFLoader 'mainSWF' (alternate_child.swf): Error #2035: URL Not Found. URL: file:///E|/testing%20grounds/load/primary_child.swf
----
Page Load Error:: Details: SWFLoader 'mainSWF' (alternate_child.swf) > Error #2035: URL Not Found. URL: file:///E|/testing%20grounds/load/primary_child.swf SWFLoader 'mainSWF' (alternate_child.swf)
Attempting to load alternate url

 

I have had a look at LoaderItem.as, and noticed that in the _failHandler, the this.url is updated to the alternateURL, then calls the errorHandler function. Which means it outputs '(alternate_child.swf) > Error', rather than '(primary_child.swf) > Error'.

 

It's not big deal because it does display the url failing just below, but if it's just a matter of swapping the order of those 2 lines, it might be cool? Or does it break a bunch of other stuff??

 

 

From 'LoaderItem.as'

               /** @private **/
	override protected function _failHandler(event:Event, dispatchError:Boolean=true):void {
		if (this.vars.alternateURL != undefined && this.vars.alternateURL != "" && !_skipAlternateURL) { //don't do (_url != vars.alternateURL) because the audit could have changed it already - that's the whole purpose of _skipAlternateURL.
			_skipAlternateURL = true;
			_url = "temp" + Math.random(); //in case the audit already changed the _url to vars.alternateURL, we temporarily make it something different in order to force the refresh in the url setter which skips running the code if the url is set to the same value as it previously was. 
			this.url = this.vars.alternateURL; //also calls _load()
			_errorHandler(event);
		} else {
			super._failHandler(event, dispatchError);
		}
	}

[Chris7777]

Sorry to be a pain, but I just realised this is a slightly bigger than originally thought, as I need a way to determine if the function onError is handling an error from the primary URL or the alternate URL - originally I was going to use the e.target.url, but this is updated before the event is dispatched.

 

Is there any way around this?

 

Cheers

[GreenSock]

Yep, that sounds reasonable. A case could be made for either way of handing it - the other way ensures that the loader instance has all of its internal changes done before the event is dispatched so that you can properly assess its state at that point. But I also see how it is intuitive to see the error reflecting the old URL when it fails. I made the change in the latest version which you can get at

[Chris7777]

Sorry I didn't even think to grab the latest version. Thanks for letting me know that it was addressed in there.

 

As always, a fantastic library of code. I let my Club Greensock expire by accident, but considering you're always ready to help I will need to register again for another year (just have to wait for next pay day )

 

Thanks again Jack

[Chris7777]

Actually just one more question - again.

 

I noticed that in LoaderItem::_failHandler() that the order was rearranged (error handler first, then update url), but not in LoaderItem::_auditStreamHandler() - would there be any harm rearranging the order in that one too?

 

Thanks

[GreenSock]

Done. In the latest version.

[Chris7777]

Dude that is awesome! Cheers mate