enableInputMethod(false) does not work in the TextArea and TextField on the linux platform (original) (raw)

Charles Lee littlee at linux.vnet.ibm.com
Mon Feb 20 00:44:14 PST 2012

Hi Anthony,

That's great. Thank you very much :-)

On 02/17/2012 08:01 PM, Anthony Petrov wrote:

Hi Charles,

The latest fix looks reasonable. Basically, by removing the enableInputMethod(true) call from peers' constructors we ensure we don't override the enable/disable state set by user code. I've filed a CR: http://bugs.sun.com/viewbug.do?bugid=7146572 Let's wait a couple more days in case anyone else wants to comment on this fix. If no further comments come, I'll push the fix next week. Thanks for the contribution! -- best regards, Anthony On 2/13/2012 12:16 PM, Charles Lee wrote: Hi guys,

Here, I want propose a even easier patch to fix this issue. Please check here: http://cr.openjdk.java.net/~littlee/OJDK-124/webrev.01/ <http://cr.openjdk.java.net/%7Elittlee/OJDK-124/webrev.01/> The patch is mainly about remove enableInputMethod in two places in XTextAreaPeer and XTextFieldPeer. If it does the right thing, would anyone help to review the patch? On 02/09/2012 02:18 PM, Charles Lee wrote: Hi Anthony,

Thank you for your review. I have changed the test case a little, which will include a button to change the input method enable[1]. Is it the dynamic thing in your mind? This test case can work well on my original patch, but I found something interesting: Enable or disable jtext/xtext input method will have nothing to do with input method. Only enableInputMethod of target has influence. I was doing some code reading about this and find that (Please correct me if wrong) : 1. jtext/xtext process InputMethodEvent from XComponentPeer.handleEvent, and eventually goes to Component.processInputMethodEvent and JTextComponent.processInputMethodEvent. There are no route for input method enable check. 2. So when input method is enabled in TextArea/TextField, jtext should be work well. 3. And when input method is disabled by enableInputMethod(false), input context will be removed from notification, and there will be no more InputMethodEvent put into queue. So peer.handleEvent will never be invoked since e is KeyEvent in the dispatchEventImpl method of Component. So I conclude that set enable input method of jtext/xtext will have no effect and my original patch can be reduced a very simple one. Just remove the target.enableInputMethod(true) in both XTextFieldPeer and XTextAreaPeer.

P.S. Why there is a jtext(JTextArea) in the XTextAreaPeer? I am missing some history here :-)

[1] public class MyAWTTest extends JFrame { private final TextArea ta; private final TextField tf; private final AtomicBoolean flag; public MyAWTTest() { super("Single Frame --- AWT Frame"); setLayout(new FlowLayout()); ta = new TextArea("TextArea component(No IM)"); ta.enableInputMethods(false); ta.setPreferredSize(new Dimension(400, 100)); add(ta); tf = new TextField("TextField component(No IM)", 52); tf.enableInputMethods(false); add(tf); flag = new AtomicBoolean(false); Button button = new Button("Click me, change the world"); add(button); button.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { if (!flag.get()) { ta.setText("TextArea component"); tf.setText("TextField component"); ta.enableInputMethods(true); tf.enableInputMethods(true); flag.set(true); } else { ta.setText("TextArea component (NO IM)"); tf.setText("TextField component (NO IM)"); ta.enableInputMethods(false); tf.enableInputMethods(false); flag.set(false); } } }); setSize(850, 360); setVisible(true); setDefaultCloseOperation(EXITONCLOSE); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { new MyAWTTest(); } }); } } On 02/07/2012 07:29 PM, Anthony Petrov wrote: Hi Charles, The general idea of the fix is OK and the fix looks fine to me. However, there's still a problem if an app enables or disables Input Methods dynamically during the app's execution. The updated status of the property needs to be propagated to the jtext or xtext somehow. -- best regards, Anthony On 2/7/2012 1:17 PM, Charles Lee wrote: Hi guys, Given a simple test case below[1], enableInputMethod(false) does not work. We can always invoke input method. [1] public class MyAWTTest extends JFrame { Component c; public MyAWTTest() { super("Single Frame --- AWT Frame"); setLayout(new FlowLayout()); c = new TextArea("TextArea component(No IM)"); c.enableInputMethods(false); c.setPreferredSize(new Dimension(400, 100)); add(c); c = new TextField("TextField component(No IM)", 52); c.enableInputMethods(false); add(c); setSize(850, 360); setVisible(true); setDefaultCloseOperation(EXITONCLOSE); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { new MyAWTTest(); } }); } } Patch @ http://cr.openjdk.java.net/~littlee/OJDK-124/webrev.00/ <http://cr.openjdk.java.net/%7Elittlee/OJDK-124/webrev.00/> The patch is mainly about: 1. Add a new method in the ComponentAccessor which help to escape the package restraints. Please check the changes in Component and AWTAccessor. 2. Remove the enableInputMethod(true) in the XTextAreaPeer and XTextFieldPeer and use areInputMethodEnabled to set jtext correctly. Please check the changes in XTextAreaPeer and XTextFieldPeer. I know it may not be a beautiful fix, but anyone interests in it?

-- Yours Charles

More information about the awt-dev mailing list