Closing submenus after one of them is clicked.

[kamal]

Hi,

I have a menuitem (submenu) which just calls a function. I want to close/collapse/hide that when the menuitem is clicked. But it should be available again when users do a mouseover on the parent menu.

Please see the following sample code from my menu_data.js:

with(XPMenuStyle=new mm_style()){
onbgcolor="#C1D2EE";
oncolor="#000000";
offbgcolor="transparent";
}

with(milonic=new menuname("Main Menu")){
style=XPMenuStyle;
top=0;
left=0;
alwaysvisible=1;
orientation="horizontal";
aI("text=File;showmenu=File;");
}

with(milonic=new menuname("File")){
style=XPMenuStyle;
overflow="scroll";
aI("text=Edit;url=javascript:startTimer();");
aI("text=New;");
}

What I want is, when 'Edit' menu is clicked, it should call the function startTimer and hide both the submenus(Edit, New). Users need to do a mouseover on file menu to see them again.

I can see a few properties like openonclick and closeonclick, but not sure how and where to use them.

Any help would be greatly appreciated.

[Kevin@Kasper]

Could someone please look into this? This problem is standing for a long time (closeonclick not working) now and i'm getting nervous people on my back that this behavior doesn't work

[Andy]

closeonclick does work with 5.09 I've just tested it:

Code: Select all

with(milonic=new menuname("Main Menu")){ 
style=XPMenuStyle; 
top=0; 
left=0; 
alwaysvisible=1; 
orientation="horizontal"; 
aI("text=File;showmenu=File;closeonclick=1;openonclick=1"); 
} 

-- Andy

[kevin3442]

Hi Kevin,

Could someone please look into this? This problem is standing for a long time (closeonclick not working) now and i'm getting nervous people on my back that this behavior doesn't work

closeonclick has worked for quite some time as far as I know. I think you may be misinterpreting what closeonclick in meant to do. Here's the definition of closeonclick from the quickrefs for menu items.

closeonclick - 40 - Closes sub menus from the showmenu command if the user clicks on the menu item.

closeonclick is sort of the opposite of openonclick; both properties apply only to menu items that open submenus (i.e., they apply to, and are only effective on, menu items whose aI() string contains a showmenu). You can use openonclick and closeonclick as style properties, to globally affect any menu using that particular style, or as menu item properties, to affect items on an individual basis. The following example uses them as item properties.

Suppose you are useing openonclick to open submenus, like so:

Code: Select all

aI("text=Item text;showmenu=subMenuName;openonclick=1;");

In this case, the "Item Text" menu item would open its submenu only when clicked, instead of when moused over. The submenu would close as you normally expect; .e.g., mousing onto another menu item, or mousing off of the menu entirely. If you added closeonclick, likes so:

Code: Select all

aI("text=Item text;showmenu=subMenuName;openonclick=1;closeonclick=1;");

then when you click the menu item, the submenu would open. With closeonclick set, while your cursor is still on the menu item, if you click the item again, the submenu will close. I.e., the submenu closes on a click of the calling item. That's what closeonclick does. It has to do with clicking a menu item that has already opened a submenu; it has no effect on clicking any other kind of menu item, and no effect on clicking anywhere else on the page.

Hope that helps to clarify closeonclick.

Kevin

[kevin3442]

Hi Kamal,

...I have a menuitem (submenu) which just calls a function. I want to close/collapse/hide that when the menuitem is clicked. But it should be available again when users do a mouseover on the parent menu.

I think what you'll have to do is add a line to the function that the menu item calls. Using the example you gave:

Code: Select all

function startTimer()
{
  closeAllMenus();
  ...
  your current code
  ...
}

Adding closeAllMenus() to the top of the function will cause all menus to close when the function runs. This will not close menus whose alwaysvisible property = 1 (so your main menu will still be available). You could also use popdown() instead of closeAllMenus(). The main difference will be that closeAllMenus() will close your submenus right away, but popdown() will close them after _menuCloseDelay msec.

You could take a slightly more complex approach and try to close only the submenu that calls the function, but then when the submenu closes, your cursor would find itself no longer inside of that menu hierarchy, and after _menuCloseDelay the whole submenu hierarchy would prpbably close anyway (I'm guessing). So, that might be a wasted effort; but if you want to give that a try, holler.

Hope that helps,

Kevin

[kamal]

closeonclick works for me as the same way you explained. But that is only applicable to menus with a submenu. What I wanted is something similar for the menus without any submenu.

Right now, I am achieving that by calling following function on click on a submenu:

menuDisplay(getMenuByName("menu1"),0);

here 'menu1' is the parent menu of the submenu clicked.

[kevin3442]

Hi Kamal,

...What I wanted is something similar for the menus without any submenu.

Right... did you see the post I sent after the one where I explained closeonclick (it looks like we cross-posted at almost the exact same time)?

Right now, I am achieving that by calling following function on click on a submenu: menuDisplay(getMenuByName("menu1"),0);
here 'menu1' is the parent menu of the submenu clicked.

I imagine that would sort of work, but I can see a few potential pitfalls:

(1) Doesn't that approach leave the submenu with containing the function-calling menu item open... sort of hanging out there all by itself, at least until you mouse off of it?

(2) What would you do for submenus that branch directly off of the main menu... you wouldn't want to close your main menu, right?

(3) You'd have to put the code in each menu item that calls one of your functions, and make sure you name the appropriate menu to close.

You might try the closeAllMenus() approach that I outlined in my previous post. It's a lot less coding and, I think, a little more versatile.

Hope that helps,

Kevin