JDK-4103252 : JDK1.2 on win32 platform hangs up when switching to other keyboard layout
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: generic
  • Submitted: 1998-01-12
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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
1.2.0 1.2beta3Fixed
Related Reports
Relates :  
JDK-4283280 - Java Application on VM is terminated by OS with the key "shift+alt"
Description
When user switches the keyboard layout, application hangs up.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2beta3 INTEGRATED IN: 1.2beta3
14-06-2004
EVALUATION [xueming.shen@Japan 1998-02-25] Even norber.lindenberg@eng conformed this bug did not occur on a us version of win32, but it does hangup all most all the fareast version of Win32, so I think this one is worth a P2, otherwise... And the reason that causes this bug is that the first time OleInitialize() is being called is at the end of AwtToolkit's constructor --AwtToolkit::AwtToolkit(), which means that the thread who constructs the AwtToolkit will become the main olethread in the process, and as the COM 's document says that a hidden window will also be created for this thread, and I found that the thread that constructs the AwtToolkit is not the same thread as the AWT-Windows thread (where we create all windows comonents), you can always find a seperated "OldMainThread" window exists in thread otherthan the "AWT-Windows" in the system. On fareast version of win32, the system also attaches a "Default IME" window to the COM's hidden window, seems to me that this "IME" causes the problem when keyboard is being switched. A deadlock occurs when the DefWindowProc try to deal with WM_INPUTLANGREQUEST message in our main AWT-Windows thread. It probablly a bug of MSIME but we do have to go around it anyway. I suggest move the call of awt_dnd_initialize() into AwtToolkit::Initialize() which will make the "AWT-Window" to be the main thread of Ole and solve above deadlock problem, the hangup is gone when I make this modification. (I assume it should be no problem to still keep the awt_dnd_uninitialize() in AwtToolkit's deconstructor). So I want to know is there any special reason that the DnD team needs to keep the AWT-Window to not be the ole main thread? is there any side-effecit to make the first time ole initialization in thw "AWT-Window" thread? I have no objection to making this change larry.cable@Eng 1998-02-25
25-02-1998
SUGGESTED FIX xueming.shen@Japan 1998-02-25 move the awt_dnd_initialize() from AwtToolkit's constructor to AwtToolkit::Initialize method.
25-02-1998