подскажите чайнику - как сделать реакцию на JMenu аналогично реакции на JMenuItem?
Тоесть - для простоты - есть менюбар, в котором есть несколько пунктов меню (JMenu). каждый пункт без своих подменю (JMenuItem).

Хочется выполнить код при выборе JMenu аналогично как при выборе JMenuItem (тоесть меню выбрано, и на нем нажата кнопка мышки или enter а не selected/deselected/canceled эвенты).
Тоесть аналогично такому коду:


попытался так:


но нет - внутрь ToolsMMMiActionPerformed не входим. тоесть ToolsMMMiActionPerformed не вызывается вообще.
а хочется ...
Спасибо!

Так ведь это и есть упомянутый selected event. Он будет вброшен и при клике мышью, и при выборе с клавиатуры.
То есть вот такой код

должен обеспечивать требуемую реакцию. Или я Вас неправильно понял?

дело в том что тогда (при использовании эвентов selected/deselected/canceled) события срабатывают даже при простом "пролете" курсора над зоной JMenu ...
причем не одно.

А JMenuItem срабатывает по клику мышки и/или enter на JMenuItem находящемся в фокусе.

Конечно это все можно обрабоать а-ля JMenuItem и еще евенты на клавиатуру добавить и кнопки распознать, но ....

Хочется однотипной обработки, и конечно в 1 месте как у JMenuItem а не плодить на каждый JMenu по нескольку методов ... хотя конечно если иначе нельзя - то конечно прийдется.
Вот я пока не могу догадаться как. решение с addActionListener элегантно и логично. но однако почему оно не работает для JMenu??

Оно?

точно. оно. теперь надо подумать как это срастить с NetBeans и его понятиями о визивиковской разработке UI. но Спасибо! направление понял.
PS: тоесть все-ж пользовать просто JMenu нельзя.

Если тебе не нужно выпадающее меню, то зачем его использовать?


Пиши руками, код будет намного проще и понятней. А если уж так хочется заниматься мышекликательством, то найди какой-нибудь плагин для бинса типа jigloo для eclipse. Самое большое его преимущество в том, что он анализирует код. А не создает отдельные файлы с описанием формочек. И все, что им нагенерировано, можно поправить руками.

так вопрос то возник именно из-за того что выпадающее меню мне НЕ нужно.
Точнее - часть головного меню - с выпадающими подменю, и 1-2 JMenu верхних - без выпадающего подменю.

А про нетбинс - не понял ... зачем ему плагины если он сам все отдлчно рисует?. При этом как в коде все может быть реализовано, так и в сериализованном виде типа ... зачем плагины то?.  толлкьо ручкам расположения и прперти внешнего вида прписывать я не буду - не производительно и не наглядно . ну да это только ИМХО ....
А класть на JMenuBar компонент типа JMenuItem как-то никто вроде не умеет. нет? ... вообщем буду копать дальше. Спасибо!

Упомянутый мною плагин отличается от бинса именно тем, что я могу написать руками все, что я хочу и как я хочу. А он все покажет, проанализировав код.

Насколько я помню бинс создает *.form файлы, в которых описан весь GUI. Может быть это и правильно, только попробуй что-нибудь поменять в сгенерированном им коде, он нифига не покажет изменений.

Sleepy_PIP, 

из своего опыта могу сказать, что aleksandy прав. Руками получается куда как более наглядный код. Кроме того, есть и еще несколько преимуществ ручного кодирования Swing GUI:

1. Сложные комбинации панелей с различными LayoutManager'ами руками пишутся на порядок быстрее.

2. Интернационализацию легче и удобнее поддерживать из ручного кода.

3. Графические построители не поддерживают многих "хаков". Яркий пример тому - отрицательные значения для Border. Это, разумеется, не лучший стиль программирования, но иногда без них никак.

4. Код переносим для работы в других IDE и даже без них. Этот пункт очень важен при работе в команде. Попробуйте-ка перетащить сгенерированный GUI из NetBeans в Idea и наоборот.

5. (Самое, на мой взгляд, важное) Когда Вы пишете GUI руками, гораздо лучше понимаете сами механизмы работы Swing. Знание общих принципов, полученных в результате такой работы с лихвой восполняет незнание многих фактов.

Таким образом, ручное написание GUI-кода экономит время, а не наоборот. 

А можно пример, когда без них никак? А то я как-то 12 лет обходился...

Имеется форма для редактирования паспорта здания по ГОСТу, в печатном виде это около 15 листов. Форма сплошь из разъезжающихся панелей, вкладок и прочих хитростей, направленных на то, чтобы вместить в один экран огромное количество контента. Это не ошибка дизайна - это прямое требование со стороны заказчика.

Сдача продукта.

Заказчик требует подвинуть кнопку ровно на 5 пикселей вверх прямо сейчас. Да, он понимает, что она наедет краем на другие компоненты. Но хочет. На исправление - 2 минуты, еще минута на автоматический build и deploy. Иначе остаешься без премии, которой тебе выдают большую часть зарплаты.

Поверьте, не от хорошей жизни такая похабень пишется.