JDK-4191924 : JDK1.2 RC, German Windows NT 4.0: Awt TextField cannot input some=
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.2.0,1.2.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-11-20
  • Updated: 1999-04-07
  • Resolved: 1999-04-07
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.2 1.2.2Fixed
Related Reports
Duplicate :  
JDK-4198833 - Cannot enter "<" in AWT TextComponents (German Keyboard)
Duplicate :  
JDK-4224297 - Win32: cannot input '_' (\u005f) by Japanese 106 keyboard on TextArea
Relates :  
JDK-4218892 - Unable to enter '!' and '=A7' characters into AWT via the french =
Relates :  
JDK-4199284 - The '|' (pipe) character cannot be generated on a non-US keyboard within Java
Description

Name: gsC80088			Date: 11/20/98

=20
In the following environemnt:

  jdk1.2 RC2,
  windows nt 4.0 (german version, sp3 installed, euro patch installed)
  german keyboard


it isn't possible to input the characters '<' '>' '|' and '=A6' into a=20
java.awt.TextField; instead of the expected characters, a question mark '?'
appears in the TextField.  All there character are located on the one key
located to the right of the left shift key on a german keyboard.


To re-produce the problem, start up appletviewer (for example: appletviewer=
=20
http://www.javasoft.com:81/), open appletviewer's Properties... dialog and
try to enter the characters <, >, | or =A6 into the 'Http Proxy Server:'
text field.
(Review ID: 43006)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2.2 INTEGRATED IN: 1.2.2
14-06-2004
SUGGESTED FIX Here are the diffs for this fix in Cricket. svdiffs 1.212 1.213 awt_Component.cpp 1621c1621 < {java_awt_event_KeyEvent_CHAR_UNDEFINED, 0} --- > {java_awt_event_KeyEvent_VK_UNDEFINED, 0} 1735a1736,1741 > // Windows treats AltGr as Ctrl+Alt > if (modifiers & java_awt_event_InputEvent_ALT_GRAPH_MASK) { > altIsDown = TRUE; > ctrlIsDown = TRUE; > } > 3711c3717 < * Method: handleEvent --- > * Method: nativeHandleEvent 3771a3778,3780 > /* Check to see whether the keyCode or modifiers were changed > on the keyPressed event, and tweak the following keyTyped > event (if any) accodingly. */ 3774a3784,3785 > UINT winKey = pMsg->wParam; > bCharChanged = FALSE; 3776,3778c3787,3789 < if (pMsg->wParam == VK_PROCESSKEY) < { < bCharChanged = FALSE; --- > if (winKey == VK_PROCESSKEY) { > // Leave it up to IME > break; 3780,3786c3791,3796 < else < { < UINT key, keyModifiers; < p->JavaKeyToWindowsKey(keyCode, &key, &keyModifiers); < if (!key) < { < key = keyCode; --- > > if (keyCode != java_awt_event_KeyEvent_VK_UNDEFINED) { > UINT newWinKey, ignored; > p->JavaKeyToWindowsKey(keyCode, &newWinKey, &ignored); > if (newWinKey != 0) { > winKey = newWinKey; 3788,3789d3797 < modifiedChar = p->WindowsKeyToJavaChar(key, modifiers); < bCharChanged = (keyChar != modifiedChar); 3790a3799,3802 > > modifiedChar = p->WindowsKeyToJavaChar(winKey, modifiers); > bCharChanged = (keyChar != modifiedChar); > break; 3791a3804 > break; // not reached 3793d3805 < break; 3797a3810 > 3817c3830,3831 < break; --- > break; // not reached >
11-06-2004
EVALUATION Fixing this requires adding two new VK_ codes to java.awt.event.KeyEvent. We prefer not to hack in a "fix" for the bug. We will add the VK_ codes in kestrel. david.mendenhall@eng 1999-03-12 Actually, VK_LESS and VK_GREATER codes already exist. We just forgot to setup the mappings in native code. We can fix this is cricket. david.mendenhall@eng 1999-03-17 Because the VK_OEM key mappings vary across locales, we will need to setup a dynamic lookup strategy. A static mapping table will be insufficient. As an interim solution, we will detect VK_UNDEFINED in nativeHandleEvent and revert to the Windows native key code. In kestrel, we will try to implement the dynamic lookup so that the correct java.awt.event.KeyEvent.VK codes are used. david.mendenhall@eng 1999-04-05 Test case is located at /test/java/awt/event/KeyEvent/ExtendedKeysTest/ eric.hawkes@eng 1999-04-07
05-04-1999