Writing Friendly Code 5. Environmentally Aware

home / web / dev / friendly

Writing Friendly Code

5. Environmentally Friendly

isReddy() is the onload event handler. It works with the next 2 functions, bugOut() and Init(), to test that the scripts have loaded and the client is supported. 

function isReddy(){ 
loadchk++;

The counter is incremented. If this attempt fails we'll get called back for 2 more tries. We see if the browser is supported, and if it is we make sure we aren't in a loop.

if (brid=="" )bugOut();
            if(loadchk>3)bugOut();

Three tries is all you get. bugOut used to be a sizable procedure. I use it in all my code. While I'm developing, I route errors to it and handle them there. I can tell I'm done with the code when bugOut doesn't have anything left to do.

   if(brid!="" && document.title ){ 

If the client is supported, if brid is not null, see if the document.title property exists. That means the document loaded - more of an event in NS when you have multiple positioned (layers) documents, as we do here. If the title exists, assign it to msgStat1. That makes msgStat1 an on switch for init(). The half second timeout makes both browsers happy. 

     msgStat1=document.title; 
                 setTimeout("init()", 500); }
}

On to init() but first, a look at the result of a failed load or no browser support.

 function bugOut(){
                return;
}

If the load test failed or the user isn't supported, bugOut returns silently and terminates the rest of the script. The user will see the page as a long scrollable document. 

---

1.g. init

function init(){
if(msgStat1=="" || infoCats.indexOf("reachcats")==-1)setTimeout("isReddy()",500);

Load test fail, try again. One of the last items in the script is one of the help messages. It has a link to a graphic called "reachcats.gif," which can be found in the string if it actually loaded. If it didn't load, go back to isReddy, increment loadchk and try again. There is another half second delay here. Long enough to parse the file and knit a sweater, usually.

   if(msgStat1!="" && infoCats.indexOf("reachcats")!=-1){

This verifies the document and script load. You'll notice that even though I like compact code, I rarely use an else branch. I'm better off saying exactly what I mean, and too often, "else" does not mean what I mean it to mean.

     window.defaultStatus=msgStat1; 
          setPg();
        }
  }

Writes the title of document to status bar and call setPg().  This tells me we are OK. When I see the title in the status bar I know the server delivered the right stuff and the browser is supported.

That's it for the client ID and load test; it is time to do what we are here for. You'll note that everything so far can be used nearly as-is in a lot of pages. The setPg function is more specific. 
A quick look at the onunload handler as we pass - I stuck it here because this is the first place you'd bail out if something I didn't think of went wrong.  

Called on an unload, reStat() first closes any extra windows we opened 

function reStat(){
   if(newwin!="" && newwin.closed==false){ 
     newwin.close();
   }

A common mistake is writing the window.closed property as if it were the window.close() method. I use both here.  If you don't check for null you get an error if you didn't open a window and try to close it. And finally, newwin is not null if you opened and then closed a window. 

I found this out when I checked for newwin and then had a window.focus() that would bring a hidden window into view for the user to close. Too cute. If the window was ever open and is now closed, the newwin test allowed the focus() call. And calling focus() to a closed window on an unload (and only on unload) gave a terrible sounding error about a server failure. I only got that error with windows I used a document.write() to, but that is enough. Forget focus() - if the window ever existed, and closed is false, close it! 

status="";
defaultStatus=""; 
}

To finish tidying up, clear the status bar on the way out. This is more of an issue in IE; sometimes Explorer will drag around a message somebody wrote to the status bar until another page overrides it. Close the windows, clear the status bar, and go. There is no noticable lag when you exit, it works right smartly.

That's it for the browser environment. Next come display decisions. Figuring out how to set the objects and events internally and on the screen. So far, the only browser-specific code was the capture Events call for Navigator, which was the only browser that read it. Everything else has been neutral, version 1 JavaScript. That is going to change soon, now that brid specified the client.

Working with the Unknown 

Comments are welcome

 


Created: Dec. 2, 1999
Revised: Dec. 7, 1999

URL: https://webreference.com/dev/friendly/