HierMenus CENTRAL: HierMenus In Progress. Controlling Rollovers from HierMenus (2/2)

[previous]

Using UponDisplay and UponHide with Rollovers

You may recall from one of our previous bulletins that the UponDisplay (or evaluate_upon_tree_show, as it is called within a menu array) and UponHide (or evaluate_upon_tree_hide) parameters allow us to execute any JavaScript expression each time a menu tree is displayed or hidden. As these parameters automatically fire only when each individual menu tree is displayed/hidden (and not refired with every display and hide of child menus of the tree) they are exactly what we need to synchronize our menu displays with our top level link rollover behavior.

On the previous page, we demonstrated one possible configuration of links for use in a HierMenus pop-up design. Let's have another look at the onmouseover setting for one of these particular links:

...
onmouseover="HM_f_SwapImage('developer',
                   'developer_but_on.gif'); 
             HM_f_PopUp('HM_Menu83',event)"
...

This is simple enough; the image rollover code (which we've defined as HM_f_SwapImage) comes first, followed by the HM code to pop-up the desired menu for this link.

When synchronizing the rollovers with the HM menu display, the first step is to move the image rollover code into the menu array definition itself. Specifically, the code to display the "on" image goes in the array's evaluate_upon_tree_show parameter, and the code to redisplay the "off" image goes in the array's evaluate_upon_tree_hide parameter. Continuing with the above example, the menu array for HM_Menu83 might begin something like this:

HM_Array83 = [
[,                      // menu width
 "mouse_x_position+10", // left position
 ,                      // top position
 ,                      // font color
 ,                      // mouseover font color
 ,                      // background color
 ,                      // mouseover background color
 ,                      // border color
 ,                      // separator color
 ,                      // top is permanent
 ,                      // top is horizontal
 ,                      // tree is horizontal
 ,                      // position under
 ,                      // top more images visible
 ,                      // tree more images visible
 "HM_f_SwapImage('developer','developer_but_on.gif')",
                        // evalute upon tree show
 "HM_f_SwapImage('developer','developer_but_off.gif')"],
                        // evalute upon tree hide
...

Now that HierMenus is controlling the image rollovers, it's important to remove the rollover code from the actual links themselves; otherwise both the links and HM will attempt to swap the images--with undesirable results. Our new link definitions now look something like the following:

...
onmouseover="HM_f_PopUp('HM_Menu83',event)"
onmouseover="HM_f_PopDown('HM_Menu83')"
...

Or, in other words, they'd look just like a standard HM pop-up implementation.

The result? Pop-up menus with external links that "remember" the state of the image rollover when the user rolls over the child menus. Have a look for yourself:

Rollovers in Older Browsers

Though it effects a very, very small subset of browsers, there remains one minor problem with our solution. A browser that does not support HierMenus--but does support basic image rollovers--will not display rollvers on the top level links. If you think about this, the reason is obvious: the rollover code for the links is handled by the HierMenus UponDisplay and UponHide mechanism; thus, if HierMenus is not loaded, that mechanism is not in place. In this case, the rollovers don't function.

As we mentioned, active browsers that will support image rollovers but will not support HierMenus is an extremely small number; small enough that most WebMasters will simply allow those older browsers to not receive image rollovers and not even bother with the following instructions. But for those who want their rollovers to be synchronized with their HierMenus and still be applied to the widest possible variety of browsers, the following JavaScript sleight of hand will do the trick.

When implementing a pop-up based design, four "dummy" functions are defined on each page:

function HM_f_PopUp(){return false};
function HM_f_PopDown(){return false};
popUp = HM_f_PopUp;
popDown = HM_f_PopDown;

These functions will prevent browsers from triggering errors in the event that a pop-up link is rolled over before the HierMenus scripts have been loaded, or in browsers that don't support the HierMenus scripts at all. (See our setup instructions if you are unfamiliar with these functions and their declaration.) Typically, they are defined as do-nothing functions, as in the above. But there's no rule that says they must be dormant!

Instead of do-nothing functions, let's modify the above code somewhat so that our "dummy" copies of HM_f_PopUp and HM_f_PopDown actually do something useful--namely, execute our image rollover code. Continuing with the internet.com example from earlier on this page, here's what the new versions might look like:

function HM_f_PopUp(menuName,e,imgName,imgSrc){
   HM_f_SwapImage(imgName,imgSrc);
   return false;
};
function HM_f_PopDown(menuName,imgName,imgSrc){
   HM_f_SwapImage(imgName,imgSrc);
   return false;
};

And then, in our links, the new onmouseover code looks like this:

...
onmouseover="HM_f_PopUp('HM_Menu83',event,
       'developer','developer_but_on.gif')"
onmouseout="HM_f_PopDown('HM_Menu83',
       'developer','developer_but_off.gif')"
...

Until the HM code is loaded, these functions will take the HM_f_PopUp calls from the image links and simply pass the additional information (the name of the image and its new source location) to the image swap routine. Once (and if) the HM code is loaded, HM will automatically redefine HM_f_PopUp and HM_f_PopDown to its own internal versions, which will quietly ignore the additional information and instead control the rollovers via the evaluate_upon_tree_show parameters. Of course, this discussion assumes that your swapping routine is compatible with the older browsers that will execute your new versions of HM_f_PopUp and HM_f_PopDown; you'll need to test that behavior out yourself for best possible results.

Conclusion

With a small amount of code and configuring, we've turned our disjointed top level rollovers into a professional menu display that allows the rollovers to "follow" the state of the displayed menus themselves. Feel free to adjust the code in this tutorial to your own liking; and remember that the evaluate_upon_tree_show and evaluate_upon_tree_hide parameters will accept practically any string-formatted JavaScript expression.

[previous]