Milonic provide full featured pull down web menus for some of the worlds largest companies
click here to see what it can do for you

Download Milonic DHTML Menu
Buy Milonic DHTML Menu

Back To Start Of Archive
Taken From The Forum: Archived Topics for the old Version 3.0 JavaScript Menu
Forum Topic: Click to view post
Last Updated: Wednesday July 18 2012 - 06:07:20

Disabling a Specific Menu Option


Poster: gerrygerry
Dated: Monday October 28 2002 - 23:02:24 GMT

I am currently trying to set up a menu with some pretty complex conditioning... I recently found that I will have to be able to disable specific menu options at run time... I dont need to disable the whole menu, or a whole submenu, just a single option on a submenu.

I understand that the menu does not currently support this feature... so I came up with an <i>idea</i> for a work around... can someone help me with the coding?

I was thinking that I could perhaps put a transparent gif in the 'text to display' part of the menu option setup with the text, and then change the z-index to be higher than that of the menu option so that it overlays the option...

Has anyone had any experience with this? Does anyone have any suggestions or a spot of code that'd help me get started on this?

I appreciate any input!

update...


Poster: gerrygerry
Dated: Thursday October 31 2002 - 1:18:48 GMT

I still haven't figured this out... please... if anyone has even the slightest idea... :cry:


Poster: kevin3442
Dated: Friday November 1 2002 - 16:30:50 GMT

Hi Gerry,

OK Gerry... I'm certainly no expert, but I'll take a stab at it. It seems like this issue comes up in one way or another from time to time, but I have yet to see a great way to deal with it... so I'll tell you my somewhat cludgey way.

There's a way to access a menu object or a menu array -- using getMenuByName() -- that is useful for doing things like showing or hiding an entire menu, or manipulating some of the properties in the ,menu array before you display a menu. But I have yet to figure out how to manipulate many specific behaviors of a menu object (like enaling/disabling programatically) once the reference is obtained. This would be a nice approach to lower level control over the menu, but I'm not there yet, so in the meantime, the only other way I can think to do what you want to do is to make the decision of what items need to be disabled when the page loads, since that's when the menu is built.

Since the menu array is javascript, it seems easiest to me to set up and test the conditions using javascript (although there may be better ways using asp and/or php). The general idea is this: Include multiple versions of the addmenu function that builds the menu. One version will have the complete menu. Other versions will have the same menu with different sets of items enabled or disabled. These different version will be inside of if blocks that test the appropriate conditions and use the appropriate menu configuration as a result. Now on to the details...

First, define a set of color variables in the menu-array.js file, below the menu Style arrays, but above the addmenu definitions. This will save you having to edit multiple lines should you decide to change the color scheme later on. Like this:
Code:
var disabled_back_color = menu_style[1];
var disabled_font_color = "76778B";
var disabled_url_str = "# onbackcolor="+disabled_back_color+";onfontcolor="+disabled_font_color+";offfontcolor="+disabled_font_color+";";

In this case, menu_style is the Style array you plan to use for the menu containing the item or items to be disabled. The idea is to use the normal "Mouse Off Backgroud Color" -- defined in the menu_style array's second element -- as the mouseover background for a disabled menu item, so that when the user points at the disabled item, the background appears not to change. The disabled_font_color should be set to something suitably "grayed out" looking... pick a color that goes with your overall scheme. The disabled_url_str is the value that will go in any disabled menu item's main URL field; note that we use a # instead of an actual URL, so that clicking on the disabled item has no effect.

Now, as a simple example, suppose you have a menu with three items: item1, item2, and item3. If a particular condition (or set of conditions) is true, then you want to display all three items. But if the condition is false, you want to disable item2. Your code might look something like this:
Code:
if (condition) {
  addmenu(menu=["menu_name",,,130,2,"",menu_style,,"left",effect,,,,,,,,,,,,
    ,"item1","item1_url.htm",,,1
    ,"item2","item2_url.htm",,,1
    ,"item3","item2_url.htm",,,1
  ])
}
else {
  addmenu(menu=["menu_name",,,130,2,"",menu_style,,"left",effect,,,,,,,,,,,,
    ,"item1","item1_url.htm",,,1
    ,"item2",disabled_url_str,,,1
    ,"item3","item2_url.htm",,,1
  ])
}

With this approach, there will still be the same number of menu items in the menu, but the disabled one will not do anything, visually or functionally. Add image controls as necessary if you use images in your menus.

Alternatively, if you don't want to go to all of the trouble of defining and using colors, to achieve the "disabled" appearance, you you could simply remove the menu item altogether, like this:
Code:
if (condition) {
  addmenu(menu=["menu_name",,,130,2,"",menu_style,,"left",effect,,,,,,,,,,,,
    ,"item1","item1_url.htm",,,1
    ,"item2","item2_url.htm",,,1
    ,"item3","item2_url.htm",,,1
  ])
}
else {
  addmenu(menu=["menu_name",,,130,2,"",menu_style,,"left",effect,,,,,,,,,,,,
    ,"item1","item1_url.htm",,,1
    ,"item3","item2_url.htm",,,1
  ])
}

In this case, the disabled menu item it more of a non-existent menu item; it simpy doesn't show up in the menu. This is easier, because there's less coding involved. But I sort of like the "disabled appearance" idea; it's more consistent with the way Windows applications work. Try them both and see what you like better.

Of course, your if statements will be based on the actual conditions that you are tracking. Which raises a potentially more difficult question: how to track your conditions. I can think of a few ways: (1) You could use cookies, which would have the advantage of letting you store a user's current conditions for reference on their next visit, but would have the disadvantage that the user must have cookies enabled. (2) You could pass a set of conditions from page to page, as parameters in the URL. You'd parse the parameter string with javascript and store the various parameters in variables that you manipulate with other scripts on the page, then pass on to the next page. (3) Finally, (my preferred approach), you could use a frame whose contents do not change. If you're working on a framed site, you're already part way there. You could use the frame that contains the main menu (assuming its source page does not get reloaded), or you could use the parent frame. If your site isn't already framed, you could try using a hidden frame for this sole purpose. Whatever frame you select, you would use it store a set of variables that would represent the conditions you have to test on each page to define the page's menu. You could either access the variables directly to retrieve or change ther values (e.g., parent.framename.variable = 1), or you could define a set of functions in the frame to do so (e.g., "get" and "set" functions).

I know that was a long post... I hope it makes sense and that you find it at least somewhat useful. Then again, there may be some wizards out there who could do the same thing in two lines! If so, let's hope they speak up, because I'd like to know too!

Hope that helps,

Kevin

Thanks!


Poster: gerrygerry
Dated: Friday November 1 2002 - 18:55:20 GMT

That was a very thorough reply Kevin.. thanks!

I think I will have to stick with a lot of server-side testing with PHP.

It's for things like this that I wish the menu was constructed with more of an OO style...
Code:
var myMenu = new menu(...);
var myMenuOption = new menuOption(...);
myMenu.add(myMenuOption);
...
if(...)
{
myMenu.options[0].disable();
}

See how nice that'd be? It would make things easier to manage... probably with shorter files sizes too! I think I remember some discussion about making the next version more OO based, but I don't recall a decision. Maybe I'll have to come up with my own version... (It'll have to be IE only though... all my apps are IE only, and anything else is way too much work to consider! ;) )

Thanks again Kevin!


Poster: Andy
Dated: Friday November 1 2002 - 18:59:34 GMT

If you give me some kind of idea on spec with regard to OOP I'll get something done with version 4.0

The main goal is to try and keep things as easy as possible to edit for the users. I know most of them could figure it out but there are still quite a lot of users that are not programmers and ease of use has always been the main aim of the menu.

Cheers
Andy

The future is OOP!


Poster: gerrygerry
Dated: Friday November 1 2002 - 19:09:40 GMT

:D Tell me what to do... I'd love to help!

:?: What sort of spec do you need? :?:

I think people could figure an OO style out... after viewing a couple examples, people would grow to love OOP (especially after handling all those little commas for so long*!).

*Discalimer: Just so I don't give the wrong impression... I love the current menu... I'm not insulting it in anyway, I'm just making suggestions