Here’s the example code:

// on DOM ready
$(document).ready(function (){

var options = {
select:menu_option_chosen
}
$(“#current_rev”).html(“v”+$.mcDropdown.version);
$(“#category”).mcDropdown(“#categorymenu”, options);
});
function menu_option_chosen() {
var dd = $(“#category”).mcDropdown();
alert(dd.getValue());

}

We’ve just released a patch which should resize the input box correctly regardless if the input is visible at init time. This should remove the need for your fix.

One issue I have found with it though. If you have the mcdropdown within a div element who’s style.display is set to “none” (i.e. hidden) it does not initialise correctly if you call the code:

$(document).ready(function (){
$(“#category”).mcDropdown(“#categorymenu”);
});

You will find that when your div block is made visible again (e.g. .style.display = “block”) then the width of the input box is zero – meaning when you come to choose an item from the menu you then cannot see what you’ve chosen.

I found a way around this which was to call the initialisation code when setting the div element’s display to block (or inline). e.g

function setDivToDisplay(divID) {
document.getElementById(divID).style.display = “block”;
// Initialise McDropdown once the div is visible again
$(“#category”).mcDropdown(“#categorymenu”);
}

Anyone who’s used client side tabbing such as DOMTAB may face a similar issue. We’ve had to put a call in from DOMTAB to our method when setting the Tab to display to call the initialisation method of McDropDown.

@DanSwitzer2: It will be an almost perfect combo-box if you improve it further more with AJAX requests to fetch the sub-trees data on demand (or cache certain top levels 1st), instead of having to build all the unordered-lists at the beginning :). Sometimes the number of records are too many to be displayed all over the screen, so paging on the fly is even greater (a small page selector at the bottom of the list layer)

When you click “inside” the text box, you actually enter the keyboard entry mode (so you can go back a node by hitting delete.) If you click the “dropdown” arrow, you’ll get the columnized suckerfish-style menu.

We have 2 distinct types of users–ones who just use the keyboard and ones that use the mouse for everything. We’re trying to accommodate both groups with a single control.

But thanks, I just noticed what you mean by clicking on it. It’s a sort of a directory/menu hybrid. I noticed, though, that there’s no way to go back/up a selection.

It’s an interesting idea, though.

It’s sort of like an expandable tree meets drop-down hybrid.

This was designed to be used as a form input control (and not really for a “menu” per se.) A lot of time was spent on the sizing aspects of the drop downs and it’s been tested with a large variety of different data configurations and as you mentioned it was not an easy problem to solve.

As you stated, this isn’t a solution for all use cases. It does work really well for our use case and we thought it would work well for others (which is why we released it as open source.)