JDK-6590085 : Cannot invoke native input method on Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0u13
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86
  • Submitted: 2007-08-07
  • Updated: 2011-01-25
  • Resolved: 2007-09-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0u14Resolved
Related Reports
Duplicate :  
JDK-6577717 - Textboxes don't work in applets under windows and linux
Relates :  
JDK-6562716 - focus request queue is not updated when rejecting focus on EmbeddedFrame (win32)
Relates :  
JDK-6480378 - Backport 5065001, 6259348 and others to 5.0 update release
Description
Reproduce:
1.Install 5u13 b01 on Windows Vista
2.Run SwingSet2 demo
3.Active native input method
4.Input native charactor in 'Frame title' of 'Intenal Frames Demo'

Problem:
Native input method cannot be invoked in SwingSet2 Demo or other java program. But native IM works well in Windows programs, say WordPad.

Platform:
Windows Vista Korean/X86/AMD64
Windows Vista zh_CN/X86/AMD64
Windows Vista zh_TW/X86/AMD64

Language:
Korean
zh_CN
zh_TW
Comments
SUGGESTED FIX The fix for "6562716 focus request queue is not updated when rejecting focus on EmbeddedFrame (win32)" have to be applied.
18-09-2007
EVALUATION The regression caused by the fix for "6480378 Backport 5065001, 6259348 and others to 5.0 update release". The fix which was applied is different from the webrev http://sa.sfbay.sun.com/projects/awt_data/5.0u12/6480378 this webrev is provided in the suggested fix section with the next comment: "The webrev of the fix can be found here:" The most problematic part of the applied fix is (awt_Component.cpp): *** 1967,1984 **** { AwtFrame *frame = (AwtFrame*)AwtComponent::GetComponent(toplevelHWnd); if (frame) { frame->SynthesizeWmActivate(TRUE); } - - sm_suppressFocusAndActivation = TRUE; - ::SetFocus(NULL); - sm_suppressFocusAndActivation = FALSE; - return mrConsume; } sm_focusOwner = GetHWnd(); sm_focusedWindow = toplevelHWnd; if (sm_realFocusOpposite != NULL) { hWndLostFocus = sm_realFocusOpposite; --- 2013,2029 ---- { AwtFrame *frame = (AwtFrame*)AwtComponent::GetComponent(toplevelHWnd); if (frame) { frame->SynthesizeWmActivate(TRUE); } return mrConsume; } + sm_suppressFocusAndActivation = TRUE; + ::SetFocus(NULL); + sm_suppressFocusAndActivation = FALSE; + sm_focusOwner = GetHWnd(); sm_focusedWindow = toplevelHWnd; if (sm_realFocusOpposite != NULL) { hWndLostFocus = sm_realFocusOpposite; *************** The part of code above must not be moved. The problem is described in "6562716 focus request queue is not updated when rejecting focus on EmbeddedFrame (win32)" The change request 6562716 is in "10-Fix Delivered" status for 5.0u14 release build 01. But I have not found the fix in the integration workspace.
18-09-2007
EVALUATION I noticed the next steps trying to reproduce the problem. 1. During the AwtComponent creation. Any association the window has with an input context is removed. For that ImmAssociateContext() is invoked with NULL as a parameter. 2. When the component is showing, ImmAssociateContext() is invoked again with new ImmContext. But only if the current ImmContext is not 0 and it is not equal to the new context. The first showing after creation skips invocation of ImmAssociateContext(). 3. WM_IME_SETCONTEXT is received. 4. WM_AWT_GETCONVERSIONSTATUS, WM_AWT_SETCONVERSIONSTATUS are received on TOOLKIT thread. 5. Three WM_IME_NOTIFY with IMN_SETCOMPOSITIONWINDOW, IMN_SETCOMPOSITIONFONT, IMN_OPENSTATUSWINDOW as wParam is received. 6. WM_AWT_ASSOCIATECONTEXT on TOOLKIT thread is recieved. 7. If the problem is reproducible, here we skip ImmAssociateContext() invocation (see step 2) Currently I cannot reproduce the problem with debug printing. So I cannot say deffenetly, why ImmAssociateContext() invocation is skipping.
20-08-2007
EVALUATION The problem is reproducible with the simplest test import java.awt.Frame; import java.awt.TextField; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; public class AWTToplevel extends Frame { public AWTToplevel() { add(new TextField()); pack(); setVisible(true); addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) { AWTToplevel.this.dispose(); } }); } public static void main (String [] args) { new AWTToplevel(); } }
17-08-2007
EVALUATION There two things about the problem. 1.) The problem looks like a thread race. Because some times it is not reproducible. 2.) I found that when the problems aoocurs java applicotion does not receives WM_IME_NOTIFY message.
17-08-2007
EVALUATION None of CJK input methods works with Swing demos in 1.5.0_13 b01 on Windows (not only on Vista). I don't see the same problem in 1.5.0_12 b04.
09-08-2007