Most of the answers I found on the forum about menus that are too long (going out of the page body) is "You shouldn't use a menu then".

But I see some cases where a menu is faster for selection than a combo, or anything else; and when it's computer generated, you don't have control on how long is the list.
And, at last, some people are working on small screen (think about EEEpc users :) )

Hopefully, soon Jack will bring Menu into the Component/Container hierarchy, and that can become a plugin.

watrboy00

23 Apr 2008, 12:14 PM

http://extjs.com/forum/showthread.php?p=149487#post149487

I extended menu to be multi columned. Needs a little work but gets the job done.

tof

24 Apr 2008, 12:54 AM

I also modified your ColumnMenu.
You just have to specify a 'maxHeight' in config, in pixels, and the columns are created automatically.
You can also specify columnWitdth and spacerWidth (defaults to 148px and 5px).

Great. I found an issue in IE6 that makes the menu expand off to the right of the screen. Also any column after the first one doesn't have the normal menu item background.

Posting your update in the thread I started and will update it once I fix the other issues.

_eb

watrboy00

24 Apr 2008, 7:25 PM

I posted an update in the other thread. Re factored the code and works/looks a lot better.

nanich

26 Apr 2008, 6:02 AM

Menu is always pointing downwards. Just for the sake of the menu why do we need to show a scrollbar at the body level?? I think this can be removed if we could able to show the dropdown menu above the button instead of showing downwards as it is happening right now.

I need your help in achieving this. please provide some logic which helps me out.

Thanks in advance

watrboy00

27 Apr 2008, 3:36 AM

I am also working on different ways to prevent issues with menu overflow other than just my column implementation. Thinking about the possibility of having scroll zones on the top and bottom of the menu to scroll the items up and down if you only want one column.

NOSLOW

28 May 2008, 6:11 AM

Sweet! Just what I was looking for. I just implemented the grid filtering plugin (http://extjs.com/deploy/dev/examples/grid-filtering/grid-filter.html) and have one filter of type list that filters by username. With over 40 users, the full list wasn't accessible. I see this as a valid issue (another common example would be a filter list on states).

To make this work with the grid filter plugin, I modified the grid\filter\Filter.js file.

First, add the assertMenuHeight function to the top of the file, then
replace this line:

Thinking about the possibility of having scroll zones on the top and bottom of the menu to scroll the items up and down if you only want one column.
That would be very nice and useful! How is the progress level currently? ;)

areichman

14 Aug 2008, 9:12 AM

I'm not sure if this will work in every case, but I had the same problem in that a long list of menu items were extending past the bottom of the page. My long menu item was part of the GridPanel, where a user can select which columns to show/hide in the view.

Adding the following CSS allowed me to control the size of the menu without any JS additions. This still gives you potentially a really long list instead of a multi-columned layout like described above, but at least its a valid solution.

I'm not sure if this will work in every case, but I had the same problem in that a long list of menu items were extending past the bottom of the page. My long menu item was part of the GridPanel, where a user can select which columns to show/hide in the view.

Adding the following CSS allowed me to control the size of the menu without any JS additions. This still gives you potentially a really long list instead of a multi-columned layout like described above, but at least its a valid solution.

@tonedeaf-
You are right. The autoscroll-y is probably a better solution. I can't remember if there was an IE6 quirk that forced me to set it to scroll or not. I think I just forced it that way to make sure it would work, since I knew the place I was using it was definitely a long menu list.

As for the fixed width, it was purely looks. My menu items were short text words, and I thought the menu looked funny as a skinny, long, menu. So I widened it even though it added some white space. I thought it looked better though. This could also be done more correctly with min-width, but it would have required another expression hack for IE6 like I used for max-height.

galdaka

3 Sep 2008, 3:28 AM

There is a better and clear way: http://extjs.com/forum/showthread.php?p=209004

I think that in future will be added to a Ext core.

Live demo: http://www.jadacosta.es/extjs/examples/scrollmenu/menus.html

Greetings,

areichman

3 Sep 2008, 3:38 AM

@galdaka-
I've seen that demo already, and while it looks nice, I personally don't like the way it functions. I'd prefer that Ext Core simply implement scrolling for these long menu items. If you have a long menu list, clicking a button to scroll up and down one element at a time like in the demo you noted can be very annoying. Scrolling is so much faster and is so much more natural, as that's the interface the users on the web are used to using for overflow content.

Regardless, I still think my CSS edit is much simpler and straight forward to use until this gets into Core. I don't like adding JS just for the sake of adding JS. And besides, the plugin you pointed out still requires more CSS than my edit does!

To me, the power of Ext is that it adds functionality that is either not possible in CSS or is really hard in CSS and this overflow is perfect and simple fit for CSS. It's exactly the sort of thing CSS is designed to handle.

Thanks...

veroxii

25 Nov 2008, 4:16 PM

I liked your implementation.

Unless your menu has long spelled out items, having a fixed width is not a good option. Also changing to overflow-y: auto will only show the vertical scrollbar if necessary.

this.el.show();
this.hidden = false;
this.focus();
this.fireEvent("show", this);
}
});Removing the cache of this.el.origHeight not only made the code simpler but fixed a few bugs I encountered:

If you made a menu with 5 items, hide it, add some items, and then show it again the menu will still be 5 items big so the extra items will spill off the bottom. Equally if you make it big to start you end up with empty space on the end when you have fewer items. This arose because we have a singleton context menu.
Menus which auto-expand (e.g. menu containing an Ext.tree.TreePanel) are broken by the caching, works fine without (though you never get a scroll bar).