The test program below gives different results on 1.2beta4 and 1.1.6

On 1.2 Ctrl + i is ignored, all other accelerators work fine.

On 1.1.6 the program seems to lock up if you pull down the menu and then make 
the menu go away, and then hit ctrl + i.  It does not do this for other
accelerator keystrokes. Also, it doesn't matter whether the accelerator for
the menu item is ctrl + i or not.  Even if you set it to something else, ctrl + i 
still locks it up after the menu has been pulled down at least once. 




import com.sun.java.swing.*; 
import java.awt.event.*; 

public class MenuTest 
{ 
	public MenuTest() 
   	{       
		JFrame frame = new JFrame(); 
      		frame.setSize(200,200);       
		JMenuBar menuBar = new JMenuBar();       
		JMenu menu = new JMenu("File");       
		JMenuItem item = new JMenuItem("Exit");       
		item.addActionListener(new ActionListener()
		{          
			public void actionPerformed(ActionEvent e) 
         		{             
				System.out.println("menu item selected"); 
         		}       
		}); 

      		item.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_I,java.awt.Event.CTRL_MASK));       
		menu.add(item); 
      		menuBar.add(menu);       
		frame.setJMenuBar(menuBar); 
      		frame.show(); 
   	} 
    
	public static void main(String[] args) 
   	{ 
      		new MenuTest();    
	} 
}

======================================================================




9/5/99   xxxxx@xxxxx   -- fine on Solaris;  problem is win32-specific.  Believe we have a dupe/open bug for this.  This report filed against 1.2.2, but changed to 
kestrel-beta, since behavior still exists there.  Accelerators look DISABLED (on both platforms).

1) run the program
   typing ctrl-i has no effect

2)
public class CtrlI extends javax.swing.JFrame {
	public CtrlI() {
		setTitle("Ctrl-I Accelerator Bug");
		buildGUI ();
		pack ();
	}
	private void buildGUI () {
		menuBar = new javax.swing.JMenuBar ();
		fileMenu = new javax.swing.JMenu ();
		fileMenu.setText ("File");
		ctrli = new javax.swing.JMenuItem ();
		ctrli.setText ("Ctrli");
		ctrli.addActionListener (new java.awt.event.ActionListener () {
		    public void actionPerformed (java.awt.event.ActionEvent evt) {
				javax.swing.JOptionPane.showMessageDialog(null,  "Menu ctrl - I called");
		    }});

		/****************************************/
		/****************************************/
		// $BUG: setting CTRL-I as accelerator does not work in jdk1.2.2 on NT/SP5,
		// typing CTRL-I has no effect
		ctrli.setAccelerator(javax.swing.KeyStroke.getKeyStroke('I',java.awt.Event.CTRL_MASK ));
		/****************************************/
		/****************************************/
		
		fileMenu.add(ctrli);
		fileMenu.addSeparator();
		exitMenu = new javax.swing.JMenuItem ();
		exitMenu.setText ("Exit");
		exitMenu.addActionListener (new java.awt.event.ActionListener () {
		    public void actionPerformed (java.awt.event.ActionEvent evt) {
				javax.swing.JOptionPane.showMessageDialog(null,  "Menu ctrl - X called");
			    System.exit (0);
		    }});
		addWindowListener (new java.awt.event.WindowAdapter () {
			public void windowClosing (java.awt.event.WindowEvent evt) {
			    System.exit (0);
			}});

		// CTRL-X works well
		exitMenu.setAccelerator(javax.swing.KeyStroke.getKeyStroke('X',java.awt.Event.CTRL_MASK ));

		fileMenu.add(exitMenu);
		menuBar.add(fileMenu);
		setJMenuBar(menuBar);
	}
	
	protected javax.swing.JMenuBar menuBar;
	protected javax.swing.JMenu fileMenu;
	protected javax.swing.JMenuItem ctrli;
	protected javax.swing.JMenuItem exitMenu;
	
	public static void main(java.lang.String[] args) {
		new CtrlI ().show ();
	}
}
(Review ID: 94874)
======================================================================

N/A

Note that this happens only when there is no other focusable component --
adding a JTextArea to the frame's content pane makes the bug go away.

What seems to be happening is a deadlock in the focusmanager.  I'm
turning it over to Hania for expert analysis:

Full thread dump:
    "Screen Updater" (TID:0xee70d330, sys_thread_t:0xedf51db8, state:CW) prio=4
        java.lang.Object.wait(Object.java)
        sun.awt.ScreenUpdater.nextEntry(ScreenUpdater.java:70)
        sun.awt.ScreenUpdater.run(ScreenUpdater.java:90)
    "AWT-Finalizer" (TID:0xee70a660, sys_thread_t:0xedf81db8, state:CW) prio=9
        java.lang.Object.wait(Object.java)
        sun.awt.AWTFinalizer.run(AWTFinalizer.java:40)
    "AWT-Motif" (TID:0xee704e80, sys_thread_t:0xedfb1db8, state:CW) prio=5
        java.lang.Thread.run(Thread.java)
    "AWT-Input" (TID:0xee704ac0, sys_thread_t:0xedfe1db8, state:R) prio=5
    "AWT-EventQueue-0" (TID:0xee7052c8, sys_thread_t:0xee011db8, state:R) prio=5 *current thread*
        javax.swing.JComponent.isFocusTraversable(JComponent.java:1378)
        javax.swing.DefaultFocusManager.getFocusableComponentAfter(DefaultFocusManager.java:164)
        javax.swing.DefaultFocusManager.focusNextComponent(DefaultFocusManager.java:88)
        javax.swing.DefaultFocusManager.processKeyEvent(DefaultFocusManager.java:73)
        javax.swing.JComponent.processKeyEvent(JComponent.java:1419)
        javax.swing.JMenu.processKeyEvent(JMenu.java:998)
        java.awt.Component.processEvent(Component.java:2209)
        java.awt.Container.processEvent(Container.java:904)
        java.awt.Component.dispatchEventImpl(Component.java:1809)
        java.awt.Container.dispatchEventImpl(Container.java:949)
        java.awt.Component.dispatchEvent(Component.java:1741)
        java.awt.LightweightDispatcher.processKeyEvent(Container.java:1479)
        java.awt.LightweightDispatcher.dispatchEvent(Container.java:1463)
        java.awt.Container.dispatchEventImpl(Container.java:936)
        java.awt.Window.dispatchEventImpl(Window.java:491)
        java.awt.Component.dispatchEvent(Component.java:1741)
        java.awt.EventDispatchThread.run(EventDispatchThread.java:79)
    "Finalizer thread" (TID:0xee700210, sys_thread_t:0xee2c1db8, state:CW) prio=1
    "Async Garbage Collector" (TID:0xee700258, sys_thread_t:0xee2f1db8, state:R) prio=1
    "Idle thread" (TID:0xee7002a0, sys_thread_t:0xee3c1db8, state:R) prio=0
    "Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12
    "main" (TID:0xee7000b0, sys_thread_t:0x39f70, state:CW) prio=5
Monitor Cache Dump:
      xxxxx@xxxxx  /EE7787F0: <unowned>
        Waiting to be notified:
            "Screen Updater" (0xedf51db8)
      xxxxx@xxxxx  /EE755268: owner "AWT-Input" (0xedfe1db8, 1 entry)
        Waiting to be notified:
            "AWT-Motif" (0xedfb1db8)
      xxxxx@xxxxx  /EE770238: <unowned>
        Waiting to be notified:
            "AWT-Finalizer" (0xedf81db8)
    <unknown key> (0xee2f1db8): owner "Async Garbage Collector" (0xee2f1db8, 1 entry)
Registered Monitor Dump:
    Thread queue lock: <unowned>
        Waiting to be notified:
            "main" (0x39f70)
    Name and type hash table lock: <unowned>
    String intern lock: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
        Waiting to be notified:
            "Finalizer thread" (0xee2c1db8)
    Dynamic loading lock: <unowned>
    Monitor IO lock: <unowned>
    Child death monitor: <unowned>
    Event monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
        Waiting to be notified:
            "Clock" (0xee3f1db8)
    Sbrk lock: <unowned>
    Monitor registry: owner "AWT-EventQueue-0" (0xee011db8, 1 entry)
Thread Alarm Q:

Here's what I am seeing with jdk1.3:

The first test program locks on Solaris 2.7. The second test program seems to work on Solaris 2.7. On Windows, neither works (i.e., pressing ctrl-i produces no effect), and neither locks up).

I suspect this is all the result of the interaction of the keyboard shortcut stuff with the focus manager. Since ctrl-i is a TAB, the focus manager gets a crack at it first, I think. In any event, we need to determince what *should* happen, and then fix it.

  xxxxx@xxxxx   1999-09-16




This is not reproducible with Merlin focus API.

  xxxxx@xxxxx   2000-10-11

======================================================================

We have an MDI application that uses a JFrame, JMenu,
JToolBar, and a JDesktopFrame in 1.2 (running on
Windows NT 4.0 using the Windows L&F) and have 
multiple accelerators- Ctrl +I is also a problem
for us.
Instead of activating our menuitem, focus changes
to our JToolBar! Subsequent Ctrl +I commands simply
transfer focus to the next button on the tool bar.
I could find no Ctrl +I listed in the Key Assignments
in the 1.2 documentation.

So the only problem is that Windows uses ctrl + i the same 
way it uses tab. Pressing tab means the same problem (if 
there is no focusable component).