A Flash Developer Resource Site

Results 1 to 5 of 5

Thread: Controlling the Logical Flow of URLLoader Listeners

  1. #1
    Junior Member
    Join Date
    Mar 2005
    Posts
    18

    Controlling the Logical Flow of URLLoader Listeners

    Hey folks,

    I'm having a bugger of a problem that I can't seem to find the solution for. I have the following code block within my ActionScript:

    Code:
    myXmlLoader.addEventListener(HTTPStatusEvent.HTTP_STATUS,catchHttpError);
    myXmlLoader.addEventListener(Event.COMPLETE, onXmlLoad);
    myXmlLoader.load(new URLRequest(rssURL));
    When the feed truly fails, then onXmlLoad never runs (or it breaks; not sure which; either way I don't have an issue). However, when the feed doesn't fail, both catchHttpError AND onXmlLoad run which creates a problem. I want to set this up so that its either one OR the other.

    As I was looking into the properties of HTTPStatusEvent.HTTP_STATUS, I noticed that I can check status, but the problem is that status can either be 200 or 0 and this is not exclusive. If any one has any suggestions or can point me in the right direction, it'd be much appreciated.

    Please note that while I'd love to be able to post the entire script, I simply cannot due to major parts of it being proprietary. When able, I will replace proprietary parts with generic data so that it can be posted.

    Thanks,

    - MT

  2. #2
    Junior Member
    Join Date
    Mar 2005
    Posts
    18

    As a quick update...

    Code:
    function catchHttpError(e:HTTPStatusEvent):void{
    	if(e.toString().indexOf("status=200") == -1) {
    		showTechDffcltMSG();
    	}
    }
    The above works flawlessly within the Flash environment but not so in a web browser. In the web browser, both display functions run as noted in the previous post.

  3. #3
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    Instead of testing for a substring in the toString result, why not test against the status property directly?
    Code:
    function catchHttpError(e:HTTPStatusEvent):void{
    	if(e.status != 200) {
    		showTechDffcltMSG();
    	}
    }
    According to the livedocs, some popular browsers don't pass the http status to the player, so it will be 0 in those cases regardless of whether it was an error status or ok status.

    You should also listen for IOErrorEvent.IO_ERROR
    Last edited by 5TonsOfFlax; 01-05-2010 at 01:00 PM.

  4. #4
    Junior Member
    Join Date
    Mar 2005
    Posts
    18
    Quote Originally Posted by 5TonsOfFlax View Post
    Instead of testing for a substring in the toString result, why not test against the status property directly?

    According to the livedocs, some popular browsers don't pass the http status to the player, so it will be 0 in those cases regardless of whether it was an error status or ok status.

    You should also listen for IOErrorEvent.IO_ERROR
    In reference to the first point, I did try that and the results were the same ( as you noted in your second statement. If that listener is so unreliable when it comes to such response codes, is my only other option IO_ERROR? I've tried working with that but I think I'll have to dig into it deeper.

    - MT

  5. #5
    Junior Member
    Join Date
    Mar 2005
    Posts
    18

    PROBLEM SOLVED: Partial solution here

    Folks,

    First let me say thanks for the help. I did solve the problem yesterday. While I can't post the code due to its proprietary nature, what I can tell you is how I solved the problem.

    As 5TonsOfFlax pointed out, the IO_ERROR was partly the way to go. I put that handler in. However, the other portion of the work that I did was put in extensive conditionals in the function called by the COMPLETE handler:

    1) IF feed is larger then 600 characters, run this block.
    2) IF feed is smaller then 600 characters (i.e. the feed is empty) then use the default feed and re-run.
    3) IF feed is smaller then 600 characters AND is the default feed then run the "technical difficulties" function.

    Either way, the issue is caught and handled appropriately. It's a shame that the HTTP_STATUS doesn't do a better job but I'm sure I'm not the only one to have that complaint.

    Thanks again all.

    - MT

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center