-
Bug
-
Resolution: Fixed
-
P2
-
1.0.2, 1.1.6, 1.2.0
-
b01
-
generic, sparc
-
generic, solaris_2.5.1
In 1.1.6 on Solaris, focus management was changed so that focus can't be set
on a lightweight component. The attached test program consists of a child
Container inside of a Frame. When first run the Frame has focus (type
a character or two), but according to its getFocusOwner() method no
component has focus.
If you click anywhere within the frame, the Container will requestFocus,
and because the Frame's FocusManager thinks no component has focus,
Container.setFocusRequest will assign focus to the Container without
telling the Frame it has lost focus. Now when you type a character,
*both* components get the event.
Although the attached test doesn't demonstrate this, other lightweight
components can request focus when the frame is in this state, and they
will receive focus along with the frame. No focus gained or lost events
are ever generated, however, breaking Swing's text components' carets.
If you activate a different frame and then re-activate the test Frame,
then only the Container will have focus (which is correct). There
however is no way programatically to force focus to the Container.
This doesn't happen on Win32 because of its "set default focus" behavior.
//=========================================================================
// Here's another test case submitted through the web that can be used.
// To reproduce,
// (1) Select menu option "menu->select to reset panel"
// (2) Click in the text field, type a few characters
// (3) Again, select menu option "menu->select to reset panel"
// (4) Type a few more characters. The characters show up in the text field,
// but no text cursor is visible so it must not have focus.
// brian.klock@eng 1998-06-12
import com.sun.java.swing.*;
import java.awt.*;
import java.awt.event.*;
public class bug extends JFrame
{
JPanel internalPanel;
JPanel mainPanel;
JMenuBar menu;
public static void main(String args[])
{
bug win = new bug();
win.setSize(300,300);
win.show();
}
public bug()
{
super("bug window");
internalPanel = new JPanel(new FlowLayout());
getContentPane().setLayout(new BorderLayout());
menu = new JMenuBar();
setJMenuBar(menu);
JMenu m = new JMenu("menu");
menu.add(m);
JMenuItem mi = new JMenuItem("select to reset panel");
m.add(mi);
mi.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
redoPanel();
}
});
getContentPane().add("North",menu);
internalPanel.add(new JTextField(10));
mainPanel = new JPanel(new BorderLayout());
getContentPane().add(mainPanel,BorderLayout.CENTER);
}
public void redoPanel()
{
mainPanel.remove(internalPanel);
mainPanel.add(internalPanel,BorderLayout.CENTER);
mainPanel.invalidate();
mainPanel.validate();
}
}
//=============================================================================
on a lightweight component. The attached test program consists of a child
Container inside of a Frame. When first run the Frame has focus (type
a character or two), but according to its getFocusOwner() method no
component has focus.
If you click anywhere within the frame, the Container will requestFocus,
and because the Frame's FocusManager thinks no component has focus,
Container.setFocusRequest will assign focus to the Container without
telling the Frame it has lost focus. Now when you type a character,
*both* components get the event.
Although the attached test doesn't demonstrate this, other lightweight
components can request focus when the frame is in this state, and they
will receive focus along with the frame. No focus gained or lost events
are ever generated, however, breaking Swing's text components' carets.
If you activate a different frame and then re-activate the test Frame,
then only the Container will have focus (which is correct). There
however is no way programatically to force focus to the Container.
This doesn't happen on Win32 because of its "set default focus" behavior.
//=========================================================================
// Here's another test case submitted through the web that can be used.
// To reproduce,
// (1) Select menu option "menu->select to reset panel"
// (2) Click in the text field, type a few characters
// (3) Again, select menu option "menu->select to reset panel"
// (4) Type a few more characters. The characters show up in the text field,
// but no text cursor is visible so it must not have focus.
// brian.klock@eng 1998-06-12
import com.sun.java.swing.*;
import java.awt.*;
import java.awt.event.*;
public class bug extends JFrame
{
JPanel internalPanel;
JPanel mainPanel;
JMenuBar menu;
public static void main(String args[])
{
bug win = new bug();
win.setSize(300,300);
win.show();
}
public bug()
{
super("bug window");
internalPanel = new JPanel(new FlowLayout());
getContentPane().setLayout(new BorderLayout());
menu = new JMenuBar();
setJMenuBar(menu);
JMenu m = new JMenu("menu");
menu.add(m);
JMenuItem mi = new JMenuItem("select to reset panel");
m.add(mi);
mi.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
redoPanel();
}
});
getContentPane().add("North",menu);
internalPanel.add(new JTextField(10));
mainPanel = new JPanel(new BorderLayout());
getContentPane().add(mainPanel,BorderLayout.CENTER);
}
public void redoPanel()
{
mainPanel.remove(internalPanel);
mainPanel.add(internalPanel,BorderLayout.CENTER);
mainPanel.invalidate();
mainPanel.validate();
}
}
//=============================================================================
- duplicates
-
JDK-4138561 Input methods disabled for Swing text components
-
- Closed
-
-
JDK-4147075 component inside a splitpane loses focus for good
-
- Closed
-
-
JDK-4152791 TextField used by the DefaultCellEditor does not relinquish focus
-
- Closed
-
-
JDK-4137191 If a cursor is not shown in JTextArea or JTextField, no CJK input is taken
-
- Closed
-
-
JDK-4139059 Cell to be edited with editCellAt() doesn't get focus
-
- Closed
-