If two menu iteams in the same menu have the same mnemonic, the second item is not accessible.

Of course, it is best to design a menu so that there are no duplicate mnemonics. Sometimes this is very difficult, though, and it would be nice to have some flexibility.

The Forte for Java IDE is extensible and can have many different configurations. Different components add menu items and assign mnemonics. Because of this, it is simply unavoidable that sometimes mnemonics get duplicated. The IDE also make extensive use of contextual menus. These are so dynamic that mnemonics have to be avoided altogether because duplicates would occur very frequently.

JMenu would have to change a bit to support duplicate mnemonics. We propose that the behavior for unique mnemonics should not be affected. The behavior should only change when there are duplicates. In this case only, the item would be highlighted when the mnemonic is pressed. A second press of the mnemonic key would move to the second item, and so on. Return would be required to actually execute the command.

Other solutions may be possible as well.




Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

When a JMenu contains two items with the same mnemonic, the
behavior of the JMenu is inconsistent with the standard behavior 
for Microsoft Windows. In Windows, when the user types a
duplicated mnemonic, the system does two things differently: 
First, it jumps to the next menu item with the chosen mnemonic,
wrapping to the top if needed. Second, it selects the menu item
but doesn't activate it. This lets the user type the mnemonic
again, to cycle through the menu items.

JMenu simply picks the first JMenuItem it finds with that
mnemonic and activates it.

The behavior in Windows is better. Swing's menus, under the
Windows L&F, should be changed to conform to Windows for two
reasons:

1) It should be consistent with the native platform's conventions.
2) It's a better way to handle the mnemonics.

This is covered by RFE 4515762, but failure to duplicate the
Windows L&F should be considered a bug, not an RFE. But it's
actually a good idea under the Metal L&F as well, for the reason
given in RFE 4515762. I'm tired of avoiding the obvious
mnemonics for a menu item, because they conflict with  xxxxx  obvious
mnemonics. I'm tired of explaining to users why I don't give them
better mnemonics.
(Review ID: 136481)
======================================================================

N/A

The feasability of this should be implemented. Not only does Windows support duplicate mnemonics, but we should give all items with a common mnemonic an equal shot at being selected. Currently, the first menu item that matches the mnemonic is invoked. This could have serious consequences when the users intention is to select the second mnemonic item but the first item is invoked.

Part of the solution would be to examine all the menuItem mnemonics in BasicMenuItemUI.MenuKeyHandler. If there are multiple matches then the menuKeyTyped method should select the *next* matching menuItem with the mnemonic rather than execute the selected menuItem. Perhaps this determiniation of which menuItem to select should be made higher in the stack like in MenuSelectionManager.

Care must be taken to ensure that the the common mnemonic bug 4213634 does not regress when fixing this bug. 

 xxxxx@xxxxx  2002-02-06

One solution that I have investigated is to move the MenuKeyHandling from the BasicMenuItemUI into BasicMenuUI.MenuKeyHander. The approach has the added benefit of reducing the ammount of events^Xb being passes to the erronious menus and menu items from the MenuSelectionManager. Currently it seems like the MenuSelectionManager.processKeyEvent() passes the KeyEvent to all the menu items that it manages until one handles and consumes the event. There is a lot of wasted processing as the menu path is constructed for every single attempt.

This solution mostly works except that mnemonic bindings would not work for stand alone popups. Perhaps the best place to put the menu mnemonics would be to handle it in BasicPopupMenuUI. For this solution, we would have to enable JPopupMenu.processKeyEvent(KeyEvent, MenuElement[], MenuSelectionManager) to fireMenuKeyEvents() that the BasicPopupMenuUI can handle. This may require adding api which is not allowed for hopper.

Another potential soltion is to rewrite the semantics of MenuSelectionManager.processKeyEvent to change the event sequence to the JMenu/JPopupMenu then JMenuItems instead of the current JMenuItems,JPopupMenu,JMenu. I'm not sure what the justification was for firing events that way. 
 xxxxx@xxxxx  2002-04-17

This solution works correctly but there can be some further optimization as described above once we can change the semantics of the api (tiger). The optimization issue is tracked as RFE 4670831.
 xxxxx@xxxxx  2002-04-18

It turns out that this is controlled by the MenuSelectionManager, which is retrieved by calling 
javax.swing.MenuSelectionManager.defaultManager(). Unfortunately, there is no way to install our own 
MenuSelectionManager, so we can't even override the default behavior. So I can't come up with a 
workaround. If we could set our own manager (RFE 4322724), we could work around this issue.

A good application framework creates options for 
developers. It doesn't place restrictions on them.