JDK-4100317 : KEY_TYPED event follows text change on Solaris, precedes it on Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.1.5,1.1.6
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS:
    solaris_2.5.1,solaris_2.6,windows_95 solaris_2.5.1,solaris_2.6,windows_95
  • CPU: x86,sparc
  • Submitted: 1997-12-18
  • Updated: 2020-02-07
  • Resolved: 2020-02-07
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Here is a program that consumes KEY_TYPED events to prevent digits from being entered:


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

public class Consume extends TextArea {

  public Consume(){
    enableEvents(-1);
  }

  public void processEvent(AWTEvent e){
    if(e instanceof KeyEvent){
	System.out.println(e+" getText: "+getText());
	if(e.getID()==KeyEvent.KEY_TYPED){
	  char c = ((KeyEvent)e).getKeyChar();
	  if((c>='0')&&(c<='9'))((KeyEvent)e).consume();
	}
    }
  }

  public static void main(String[] args){
    Frame f = new Frame("No Numbers");
    f.add("Center",new Consume());
    f.pack();
    f.show();
  }

}


This functions properly on Windows but not on Solaris.

Output from typing "A1" on Windows:

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=16,keyChar=''] on text0 getText: 
java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65,keyChar='A',modifiers=Shift] on text0 getText: 
java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyChar='A'] on text0 getText: 
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65,keyChar='A',modifiers=Shift] on text0 getText: A
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=16,keyChar='',modifiers=Shift] on text0 getText: A
java.awt.event.KeyEvent[KEY_PRESSED,keyCode=49,keyChar='1'] on text0 getText: A
java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyChar='1'] on text0 getText: A
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=49,keyChar='1'] on text0 getText: A



On Solaris - note that the text has already changed when the KEY_TYPED occurs,
thus ignoring the consume():

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=16,keyChar=''] on text0 getText: 
java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65,keyChar='A',modifiers=Shift] on text0 getText: 
java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyChar='A'] on text0 getText: A
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65,keyChar='A',modifiers=Shift] on text0 getText: A
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=16,keyChar='',modifiers=Shift] on text0 getText: A
java.awt.event.KeyEvent[KEY_PRESSED,keyCode=49,keyChar='1'] on text0 getText: A
java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyChar='1'] on text0 getText: A1
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=49,keyChar='1'] on text0 getText: A1

Comments
MToolkit was removed in jdk7.
07-02-2020

EVALUATION Not reproducible using JDK6.0/XToolkit
05-12-2005

SUGGESTED FIX Pick one behavior, document it, and implement it on all platforms. Being a Solaris guy, I have gotten used to its way. But either is fine.
17-09-2004

EVALUATION My theory: the problem is that X doesn't have an equivalent to the KEY_TYPED event, while Windows does (WM_CHAR). So, we post the keypressed and keytyped events on the X-Windows keypress, and the motif peer responds by inputting the character based on the keypressed event. Our best chance of fixing this may be XAWT. The Windows behavior is correct. ###@###.### 2002-12-18
18-12-2002