JDK-4114565 : AWT text components should input using KeyTyped, not KeyPressed
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.1.1,1.1.5,1.2.0,1.3.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS:
    generic,solaris_2.6,windows_95,windows_nt generic,solaris_2.6,windows_95,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1998-02-23
  • Updated: 2006-01-23
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
AWT text components, eg java.awt.TextField, behave differently in terms
of the Java event sequences which cause text to be input and
displayed in these components

Also they are different than the Swing components which are
considered to demonstrate the correct behaviour.

Here is a summary

The types of Java key event are KeyPressed, KeyReleased and KeyTyped

The JTextField enters input in response to a KeyTyped event and is
unaffected by KeyPressed, KeyReleased.

I would regard this as correct behaviour.

Consuming the keyPressed event should not prevent the KeyTyped event
from being generated. They are separate AWT events, and consuming that
event prevents it being processed by components, it does not prevent
the other event generation.

In the AWT case however there are different behaviours between NT and Solaris

NT: The TextField enters input in response to a KeyTyped event.
Consuming the KeyTyped prevents the text from appearing, that is correct.

But consuming the KeyPressed event also prevents the KeyTyped event being
generated. This is wrong. 

i.e. NT apparently needs to see the KeyPressed AND the KeyTyped,
but not the KeyReleased.

It should not be dependent on KeyPressed (or KeyReleased)
    
Solaris: The TextField enters input immediately in response to a KeyPressed
event. This is wrong: it should use KeyTyped.

This can be demonstarting by consuming the KeyTyped : it does not prevent
input as  its too late.
There is a bug id 4069196 on this related issue.

Because of this, bug 4069196 and this one needs to be fixed at the same
time.

ie consuming KeyPressed and KeyReleased events should have no bearing
on KeyTyped events, or the interpretation of KeyTyped events by text
components.

-------------------

// adapted from the test case for bug # 4069196

import java.awt.*;
import java.awt.event.*;

public class Bug4114565 extends Frame implements WindowListener,ActionListener,
                                                KeyListener {
public Bug4114565() {
                super();
                setSize(300,300);
                setLayout(null);
                addNotify();
                setFont(new Font("Helvetica", Font.PLAIN, 12));
                Insets ii = getInsets();
                textField1 = new TextField(12);
                textField1.addActionListener(this);
                textField1.addKeyListener(this);
                add(textField1);
                textField1.setBounds(ii.left + 24,ii.top + 90,96,32);
                setTitle("Key Event Test");
                addWindowListener(this);
}

public Bug4114565(String title) {
            this();
            setTitle(title);
}

private static void show_event(KeyEvent k,String source) {
                TextField t;
                char c;
                t = (TextField) k.getComponent();
                int lgth = t.getColumns();
                String s = t.getText();
                System.out.println(source + " ->" + k + "  getText ->" + s);
                if(lgth <= s.length()) {
                        System.out.println("NO MORE CHARACTERS");
                        k.consume();
                }
                return;
}

public void keyTyped(KeyEvent k) {
        k.consume(); // 4114565  (has no effect)
        show_event(k,"keyTyped");
}

public void keyPressed(KeyEvent k) {
        show_event(k,"keyPressed");
        // System.out.println("keyPressed ->" + k);
                // k.consume(); // 4114565  (since chars entered here,
                                // this event must NOT be consumed
}

public void keyReleased(KeyEvent k) {
        show_event(k,"keyReleased");
        // System.out.println("keyReleased ->" + k);
                // k.consume(); // 4114565 (has no effect)
}

public void actionPerformed(ActionEvent e) {
        System.out.println("actionPerformed ->" + e);
}

public void windowClosed(WindowEvent event) {
}

public void windowDeiconified(WindowEvent event) {
}

public void windowIconified(WindowEvent event) {
}

public void windowActivated(WindowEvent event) {
}

public void windowDeactivated(WindowEvent event) {
}

public void windowOpened(WindowEvent event) {
}

public void windowClosing(WindowEvent event) {
                if(true)
                        {
                        Component fc = this.getFocusOwner();
                        if(fc == null)
                                System.out.println("getFocusOwner() is null");
                        else
                                System.out.println("getFocusOwner() ->" + fc);
                        setVisible(false);         // hide the Frame
                        dispose();      // free the system resources
                        System.exit(0);
                        }
                else
                        System.out.println("System.exit() skipped");
}

static public void main(String args[]) {
        Bug4114565 f1 = new Bug4114565();
        f1.pack();
        f1.setVisible(true);
}

TextField textField1;

}

Comments
PUBLIC COMMENTS AWT text components use KeyPressed for text input, either alone or also requiring an associated KeyTyped event. This is wrong. text components should usually look only at KeyTyped and consuming KeyPressed and KeyReleased events should have no bearing on KeyTyped events, or the interpretation of KeyTyped events by text components.
17-09-2004

EVALUATION 3/29/2000 kevin.ryan@eng -- AWT text comps still used keyPressed, as of kestrel-rc2 (1.3.0 rc2-Y). ============================================================================== See 4100317, which is a very similar issue on Solaris. However, it doesn't mention the problem on NT. ###@###.### 2002-12-18
18-12-2002