Steps to reproduce:

1. Install Chenese (Taiwan) / Chinese (Traditional) Quick input method support
2. Run any Swing application with text area, for example, Notepad demo
3. Switch into Chinese and start typing into the text area
4. If you don't see IM candidate window while typing, the bug is reproduced
5. Deactivate window (click on the desktop)
6. Acivate window (click on the text area). Candidate window is shown

The problem is reproduced starting from 7.0-b02, so it may be related to 6359035. There is another change request about focus issues revealed by 6359035: 6542975 - but the fix for it doesn't solves this new problem with candidate window.
Posted Date : 2008-09-01 09:52:08.0

N/A

Interesting that the problem is not reproducible on Windows Vista. At the same time it is reproducible on Windows XP.
Posted Date : 2008-09-01 11:25:45.0

To open the candidate window AWT goes through the following steps:

1. the system posts the WM_IME_NOTIFY (IMN_OPENCANDIDATE) message to the AWT top level
2. AWT's subclassing procedure consumes the message (AwtComponent::WmImeNotify)
3. calculates the position of the candidate window (AwtComponent::InquireCandidatePosition)
4. tries to pass the WM_IME_NOTIFY message to the next handler by the ::DefSubclassProc call (AwtComponent::OpenCandidateWindow)
5. finally, the last handler in the subclass chain should call the original window procedure for the AWT top level.

Most likely, ::DefSubclassProc fails to call ::DefWindowProc and the step 5 is missed. This happens because AWT calls ::DefSubclassProc in the context of the custom message (WM_AWT_OPENCANDIDATEWINDOW) instead of the WM_IME_NOTIFY message.

The IME's handlers of the WM_IME_NOTIFY message are first hanlders in the subclass chain. So AWT doesn't need to call ::DefSubclassProc and we may directly call the original window procedure by the ::DefWindowProc call
Posted Date : 2008-09-03 10:50:43.0

1

1

222

33

3

55

222

vote

vote

vote

vote

any fix ?

Bug Fixes in 1.6.0_11.