Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4197167
Votes 1
Synopsis KeyEvent differences between Solaris and Windows
Category java:classes_awt_im
Reported Against 1.2fcs
Release Fixed
State 11-Closed, duplicate of 4186905, bug
Priority: 3-Medium
Related Bugs 4186905
Submit Date 14-DEC-1998
Description
When we inputted space key or enter(return) key in JTextField, the differences of action of KeyEvent happened between on Solaris and Windows NT.
We found the differences of action of KeyEvent in following four cases.

- case1 : when we input <space> in JTextField without mode of inputting 
          japanese
- case2 : when we input <space> in JTextField with mode of inputting japanese
          (as no translation)
- case3 : when we input <space> in JTextField with mode of inputting japanese
	  (as translation)
- case4 : when we input <enter> (Return key) in JTextField with mode of
	  inputting japanese (as translation)

The detail of result is below (o : KeyEvent appears , x : KeyEvent didn't appear ),

- case1 :
	                 Solaris Wnn6  ATOK8 cs00  WinNT(MS-IME97,ATOK11)
keyPressed              	o     	 o     o     o
keyTyped                	o     	 o     o     x
keyReleased             	o     	 o     o     o

- case2 :

               		 Solaris Wnn6  ATOK8 cs00  WinNT(MS-IME97,ATOK11)
keyPressed              	o     	 x     x     x
keyTyped                	o     	 x     x     x
keyReleased             	o     	 x     x     o

- case3 : 

               		 Solaris Wnn6  ATOK8 cs00  WinNT(MS-IME97,ATOK11)
keyPressed              	x     	 x     x     x
keyTyped                	x     	 x     x     x
keyReleased             	x      	 x     x     o

- case4 :

               		 Solaris Wnn6  ATOK8 cs00  WinNT(MS-IME97,ATOK11)
keyPressed              	x     	 x     o     x
keyTyped                	x     	 x     o     x
keyReleased             	x     	 x     o     o


These results may be dependent of each IME, but we think that java must be
independent of platform. So, especially, we hope next points.
1. In case1, keyTyped event happens on windows NT.
2. In case2, case3 and case4 , keyReleased event don't happen on Windows NT.

Then these results can be reproduced by following IMFTest.java .

---------------------------- IMFTest.java ------------------------------------

import javax.swing.*;
import javax.swing.text.*;
import java.awt.*;
import java.applet.*;
import java.awt.event.*;

public class IMFTest extends JPanel implements KeyListener {

	private JTextField inputField;
	private String emptyString = "";

	public IMFTest() {

      		inputField = new JTextField(10);
		add(inputField);
      		inputField.addKeyListener(this);

	}

        public void keyTyped(KeyEvent e) {
		System.out.println("KeyTyped event is pressed.");
        	Object o = e.getSource();
        	if (o instanceof JTextComponent) {
          		JTextComponent tc = (JTextComponent)o;
          		String input = tc.getText();
          		if (input.length() == 0 || input.charAt(0) != '"') {
            			char c = e.getKeyChar();
            			if (Character.isLetter(c) && Character.isLowerCase(c)) {
              				e.setKeyChar(Character.toUpperCase(c));
            			}
          		}
        	}
        }
	public void keyPressed(java.awt.event.KeyEvent e) {
		System.out.println("KeyPressed event is pressed.");		
	}

        public void keyReleased(KeyEvent e){
		System.out.println("KeyReleased event is pressed.");
        	Object o = e.getSource();
        	if (o instanceof JTextComponent) {
          		JTextComponent tc = (JTextComponent)o;
          		switch (e.getKeyCode()) {
          			case KeyEvent.VK_ENTER:
          			case KeyEvent.VK_SPACE:
          			{
            			String input = tc.getText();
            			if (input.equals(emptyString) || input.equals("")) {
              				if (e.getKeyCode() == KeyEvent.VK_ENTER) {
                			} else {
                			}
            			} else {
              				String s = null;
              				if (e.getKeyCode() == KeyEvent.VK_ENTER) {
                				s = input;
              				} else {
                				s = input.substring(0,input.length() - 1);
              				}              				
            			}            			
            			tc.setText(emptyString);
				}
          			break;
			}
		}
	}
	public static void main(String args[]) {
		JFrame frame = new JFrame("IMF Test");
		IMFTest IMFpanel = new IMFTest();
		frame.getContentPane().add(IMFpanel);
		frame.pack();
		frame.setSize(200,200);
		frame.setVisible( true );
	}
}

-------------------------------------------------------------------------------------      
Work Around
N/A
Evaluation
Tim -- I'm not sure if this is yours, Hania's, or Brian Becks. Reassign as you
see fit.
  xxxxx@xxxxx   1999-01-07

JTextField(JTextComponent) is doing nothing special before events are passed to listeners. This is an awt/i18n/im issue. I am reassigning to classes_awt_im.
scott.violet 1999-02-03



This behavior is highly dependent on the input method being used. Input methods on the different platforms, and often on the same platform, behave differently. It would be extremely difficult to try and compensate for these differences in the Java runtime, so that applications get exactly the same behavior everywhere.

I think it is more useful to think about which differences cause real problems, 
and try to eliminate those.

As for differences in keyPressed and keyReleased events that have to do with 
keys that generate real characters, we think that they shouldn't matter. To 
obtain character input, applications and applets should listen to keyTyped 
events and input method events. In JDK 1.2, we have updated the KeyEvent 
documentation to clearly recommend keyTyped over keyPressed and keyReleased 
events, stating that the latter are platform and locale dependent.

We neglected to mention that input method events need to be handled together 
with keyTyped events to get the complete character input. This is obvious to 
anybody implementing an active client of the input method framework - see
http://java.sun.com/products/jdk/1.2/docs/guide/intl/spec.html#Input Method API
- but it may be a surprise to Swing users, because they may not be aware that 
Swing text components are active clients.

Asked submitter whether any of these differences cause real problems - no response. In any case, we should update the documentation to clearly spell out the relationship between KeyEvent and InputMethodEvent, in particular for Swing.
  xxxxx@xxxxx   1999-03-03


Some of the issues have been addressed as part of 4186905 (JTextPane no longer dispatches keyTyped events to a KeyListener). Other issues remain.
  xxxxx@xxxxx   1999-04-14


One unnecessary difference is that the Windows host adapter converts individual unprocessed key events into input method events (AwtComponent::WmChar), while the X host adapter doesn't do this.
  xxxxx@xxxxx   1999-04-23


>1. In case1, keyTyped event happens on windows NT.

This problem is already fixed in 4186905.

>2. In case2, case3 and case4 , keyReleased event don't happen on Windows NT.

I don't think this causes a problem in the real world.  If it does, please file another bug with the specific problem.

  xxxxx@xxxxx   1999-09-09
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang