DHTML Lab: Hierarchical Menus Version 3 | 20

Hierarchical Menus: Version 3
Explorer menu re-creation

WebReference

Click the link above to reveal menu. Click anywhere on the page to hide menu.

Parameters used for the menus on this page:

menuVersion = 3;
menuWidth = 120;
childOverlap = 50;
childOffset = 5;
perCentOver = null;
secondsVisible = .5;
fntCol = "black";
fntSiz = "10";
fntBold = false;
fntItal = false;
fntFam = "sans-serif";
backCol = "#DDDDDD";
overCol = "#CCCCCC";
overFnt = "purple";
borWid = 0;
borCol = "black";
borSty = "solid";
itemPad = 3;
imgSrc = "tri.gif";
imgSiz = 10;
separator = 1;
separatorCol = "red";
isFrames = false;
keepHilite = false; 
NSfontOver = false;
clickStart = true;
clickKill = true;
showVisited = "";

In script listings, cross-browser code is blue, Navigator-specific code is red, and Explorer code is green.

menuLoc.document.body.onunload = IEunloaded;

The Good News

IE4 introduced the onreadystatechange event handler for these objects/elements:

• APPLET
• EMBED
• IMG
• LINK
• OBJECT
• SCRIPT
• STYLE
• document

As you can tell from the type of objects that fire this event, they are elements that load a file or control (the first seven), or are files themselves (document). That is, objects that require a server visit to load fire the readystatechange event.

Fires whenever the ready state for the object has changed.

Each object can choose to expose which set of ready states it is exposing. This event should be fired whenever the ready state is changed.

When an element changes to the loaded state, this event fires immediately before the firing of the load event. This event will not bubble. Events that do not bubble can only be handled on the individual object that fired the event.

Microsoft Copyright Notices for Materials Used

Five of the objects (IMG, LINK, OBJECT,SCRIPT, STYLE and document) have a readyState property which reflects the current state of the object. APPLET and EMBED load objects foreign to Explorer and cannot be queried. In the case of APPLET, it is a Java applet, and for EMBED, it could be any plug-in.

When the readystatechange event fires, the readyState property of the object is updated to one of four values:

unitialized	the object is not initialized with data
loading	the object is currently loading its data
interactive	the object can be interacted with even though it is not fully loaded
complete	the object is completely loaded

It stands to follow, therefore, that we can track the state of our frame's document by applying the onreadystatechange handler to it, and when it unloads (anything but "complete"), wait for it to load ("complete"), then rebuild the menus. Right?

Wrong.

The Bad News

In the documentation, above, it states that onreadystatechange "should be fired whenever the ready state is changed." I could not capture it, although it does fire since the readyState property of the document is correctly updated.

Since Explorer cannot tell us when the state changes, we must do it ourselves, in the following way. The IEunloaded() function, called when the menu frame unloads, looks like this:

function IEunloaded() {
    initVars();
    isLoaded = false;
    setTimeout("keepTrack()",50)
}

IEunloaded() re-initializes our variables, sets isLoaded to false, then waits 50 milliseconds before calling a new function, keepTrack(). This pause gives the frame the time it needs to complete the unload and therefore change the readyState of the document from "complete" to "loading". When keepTrack() is called, a new page is loading into the main frame.

function keepTrack() {
    if (menuLoc.document.readyState == "complete") {
        initVars();
        startIt();
    }
    else {
        setTimeout("keepTrack()",50);
    }
}

keepTrack() checks the frame document's readyState property at regular short intervals (50 milliseconds). If readyState is "complete", it means the page has loaded, so we can rebuild our menus, by re-initializing the variables and calling startIt().