yes, that is a problem. It can be minimized according to the creation order, but from empiric experience in my clicktracker I have 2 dropdown menus very near to other menus and gui elements, which don't get clicked. Somehow that works fine there. I could try to find out why and add it to the help patch.

I think when jp.menu was launched, someone suggested a global switch, so that it assures all other menus stay closed when one is open.

And one problem will always be that the programmer must reserve space in the canvas for a full expanded menu - unless he/she does a dynamic canvas, based on the menu's dimensions and list size.

I found an important difference between [guilla/dropdownMenu] and
[jmmmp/jp.menu]. The former uses sliders as buttons while the latter
uses scalars of data structures. The problem with sliders is that (like
any other regular GUI widget in Pd) the lowest one gets the click if
there is an overlap. When [dropdownMenu] is placed right on top of
other GUI stuff, in expanded view you can either not click the items or
you cannot see them, depending on which order [dropdownMenu] was
created relative to the other stuff. Thus, [dropdownMenu] doesn't help
in saving screen estate.

It seems with expanded view of [jp.menu] covering other stuff, you can
still click the listed items, though the widgets below gets the click,
too. It's not ideal, but one can at least "protect" other stuff by
registering whether [jp.menu] is expanded or not.

It turns out it's a science to get this right. 

Roman

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and accou