| home / web / dev / menus / intro3 |   
|
|
|
|
A number of readers have asked for three related menus. We've extended the 2-D array technique to three dimensions to make three related menus. Try changing the first menu and see what happens. Here's a stripped down version for download.
| Choose a subject: |
-> | Choose a topic: |
-> | Choose a subtopic: |
| Choose a subject: |
-> | Choose a topic: |
-> | Choose a subtopic: |
The code is similar to the 2-D version, with the following changes.
In O (for second menu option) we create a new array for each element to store a possible third dimension, and add two properties as before (text, value) only we now do it within the O function (using new myOptions here doesn't work).
Function OO fills the third dimension to our 3-D array, and acts like O did in the 2-D version, saving our two variables as properties of the element. Once we have the 3-D array filled up with options, we only need to refer to the array in the right place to extract the menu options we want.
Relating the first to the second menu is similar to our 2-D example, except we also call relate2 to change the third menu based on the second.
The one change here from the original relate function is the call to relate2, which updates the third menu, based on the first and second menus. This is where it gets tricky as we have to know the current selection of both menus 1 and 2 to find the option values of menu 3 in our 3-D array.
Bug Fix v 1.3 - On multiple select lists, there is no default selection, so when you choose an option from the second menu's list, you'd get an error, since there's no selection in the first menu's list. Setting the first option in the first menu's list as the default selection eliminates this bug.
Just in case the user forgets to set the first selection to SELECTED in multiple related lists, we'll check for an unselected parent menu option in the code.
relate2 is called by the second menu (and the first, through the relate function) to change the third menu, and is similar to relate, with two changes: the fromRelate boolean and our third dimension, k. When called on its own, relate2 simply changes the third menu using our 3-D array to create option values. When called from relate, we set fromRelate to true, and we increment our form number to refer to the second menu (without this k would be undefined). In either case k finds the current selection of the first menu, which we use later when referencing our 3-D array.
The first highlighted line above increments the formNum to refer to the second menu if this function is called fromRelate, as we pass in the first menu's name when we call relate from the first menu. The second highlighted line fills k with the selectedIndex of the first menu. The next line does a check on k, if undefined (-1) we assume the first option is selected (k=0). The next line increments formNum to refer to the third menu, whose options we redefine from the 3-D array. (k=first menu selection, (j=second menu selection, and i=third menu options).
Internet Explorer 4+ behaved strangely after returning to the form, in version 1.2 of these related menus. After you selected say Contents -> Internet -> FAQs and then hit the back button, the menus were out of synch (this also occured on the 2-D menus to a lesser extent). This we like to call the IE4 MEMORY-CACHE-STORING-ONLY-INDEX-AND-NOT-CONTENT bug.
Internet Explorer 4+ remembers the index of each SELECT menu but not the contents of each SELECT, so it gets it wrong. Explorer's memory cache stores the selected index only of the SELECT menu, and not the content at the time of selection. When you return to a page, it displays the default contents of each SELECT, grabs the stored index from cache and aligns the default contents to that index. Netscape, on the other hand, seems to remember both index and contents. Here's the fix.
Bug Fix v1.3 The way around this is to avoid the problem altogether and reset all your forms. You can either do this onload in the HEAD or at the end of your BODY. We chose the onload method:
Thanks to Peter Belesis (pbel@internet.com) for pointing this out.
There is a workaround for the above back button problem in IE5, that will maintain persistence of the SELECT menus. Here are the steps:
<META NAME="save" CONTENT="history">
<STYLE>
.saveHistory {behavior:url(#default#savehistory);}
</STYLE>
... <SELECT....ID=sel4 CLASS=saveHistory....> <SELECT....ID=sel5 CLASS=saveHistory....> ...
window.onload = IEsetup;
function IEsetup(){
if(!document.all) return;
IE5 = navigator.appVersion.indexOf("5.")!=-1;
if(!IE5) {
for (i=0;i<document.forms.length;i++) {
document.forms[i].reset();
}
}
}
We've incorporated these improvements into this page, view source to see how it works. Thanks again to Peter Belesis for pointing this out.
Comments are welcome
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: Mar. 9, 1997
Revised: July 22, 1999
URL: http://webreference.com/dev/menus/intro3.html
