-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
5.0
-
x86
-
windows_2000
A DESCRIPTION OF THE REQUEST :
The Java API should provide some way to distinguish between InputMethods who's Locale is identical, but which have different Keyboard layouts.
The methods InputContext.getLocale() and InputContext.selectInputMethod() provide no way to distinguish between such similar InputMethods.
Regarding what may be a related bug id: 4067506 - I believe the evaluation statement from 2000-06-26 is wrong. The methods InputContext.selectInputMethod() and InputContext.getLocale() provide no way to query the "Keyboard layout" in effect for the Input language. On Windows 2000, you can create two different "input locales", each with the same language [ie: English (United States)], but one "input locale" has a "Keyboard layout/IME" of "US", while the other has an "Keyboard layout/IME" of "French". There is no way in Java to distinguish between these two.
Adding a method like "InputContext.getKeyboardLayout()" would at least allow us get the active Keyboard Layout. Unfortunately, this would not solve the problem of how to set the InputMethod to the desired "Input language"/"Keyboard layout" value.
JUSTIFICATION :
We can not distinguish between two InputMethods with the same Input Language, but which have differing Keyboard layouts. Our product requires a certain Input Language AND Keyboard layout, and needs a programatic way to at least inspect, and possibly correct these settings.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I'd like to be able to query for the current Input Language AND Keyboard layout. Ideally, I'd also like to be able to set the active InputMethod/Context to an InputMethod with a known Keyboard Layout.
ACTUAL -
Currently, there is no way to know which Keyboard layout is active for a given InputMethod. Also, there is no way to know which InputMethod/Keyboard layout will be used if two similar InputMethods exist (as defined above) when setting the InputMethod via InputContext.selectInputMethod(Locale).
CUSTOMER SUBMITTED WORKAROUND :
None, except possibly making native calls to the OS.
###@###.### 2005-03-07 09:54:40 GMT
The Java API should provide some way to distinguish between InputMethods who's Locale is identical, but which have different Keyboard layouts.
The methods InputContext.getLocale() and InputContext.selectInputMethod() provide no way to distinguish between such similar InputMethods.
Regarding what may be a related bug id: 4067506 - I believe the evaluation statement from 2000-06-26 is wrong. The methods InputContext.selectInputMethod() and InputContext.getLocale() provide no way to query the "Keyboard layout" in effect for the Input language. On Windows 2000, you can create two different "input locales", each with the same language [ie: English (United States)], but one "input locale" has a "Keyboard layout/IME" of "US", while the other has an "Keyboard layout/IME" of "French". There is no way in Java to distinguish between these two.
Adding a method like "InputContext.getKeyboardLayout()" would at least allow us get the active Keyboard Layout. Unfortunately, this would not solve the problem of how to set the InputMethod to the desired "Input language"/"Keyboard layout" value.
JUSTIFICATION :
We can not distinguish between two InputMethods with the same Input Language, but which have differing Keyboard layouts. Our product requires a certain Input Language AND Keyboard layout, and needs a programatic way to at least inspect, and possibly correct these settings.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I'd like to be able to query for the current Input Language AND Keyboard layout. Ideally, I'd also like to be able to set the active InputMethod/Context to an InputMethod with a known Keyboard Layout.
ACTUAL -
Currently, there is no way to know which Keyboard layout is active for a given InputMethod. Also, there is no way to know which InputMethod/Keyboard layout will be used if two similar InputMethods exist (as defined above) when setting the InputMethod via InputContext.selectInputMethod(Locale).
CUSTOMER SUBMITTED WORKAROUND :
None, except possibly making native calls to the OS.
###@###.### 2005-03-07 09:54:40 GMT
- relates to
-
-
- Resolved
-