Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6680988

KeyEvent is still missing VK values for many keyboards

    Details

    • Subcomponent:
    • Resolved In Build:
      b55
    • CPU:
      x86
    • OS:
      windows_2000, windows_xp
    • Verification:
      Not verified

      Backports

        Description

        J2SE Version (please include all output from java -version flag):
        java version "1.6.0_05"
        Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
        Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

        Does this problem occur on J2SE 5.0.x or 6.0? Yes / No (pick one)
        Yes

        Operating System Configuration Information (be specific):
        Microsoft Windows XP [Version 5.1.2600]

        Bug Description:
        KeyEvent is still missing VK values for many keyboards.

        This is related to RFE 4068241 and all the reports related to that one.

        Using a Hebrew Keyboard the keys i) [, < Tav] ii) [. > Final Tzadeek] and iii)
        [; : Final Fay] all map to VK_UNDEFINED.

        Likewise with a Danish Keyboard (and I assume also Norwegian) the keys for their last
        3 letters of the alphabet i) [ae] ii) [oe] iii) [aa] also all map to VK_UNDEFINED.

        In the case of Hebrew the other Hebrew letters map to the English letters on the same
        key (like Alef maps to VK_T) which is fine, for the 3 problem keys there already mappings
        to the English Symbols on the same key (for example using Hebrew [' " ,] maps to VK_COMMA)
        so it would not help to make [, < Tav] map to VK_COMMA, as that would cause a Comma to be
        typed instead of a Tav.

        This makes Screen Recording and Playing back very difficult as these 6 keys (3 in each
        language) can not be recorded.

          Issue Links

            Activity

            Hide
            art Artem Ananiev added a comment -
            BT2:EVALUATION

            Since this change request about adding new VK_ constants into KeyEvent class, it looks like an RFE rather than a defect...
            Show
            art Artem Ananiev added a comment - BT2:EVALUATION Since this change request about adding new VK_ constants into KeyEvent class, it looks like an RFE rather than a defect...
            Hide
            yan Yuri Nesterenko added a comment -
            BT2:EVALUATION

            This is clearly RFE. Actually, we already have a solution based on a different keymapping paradigm waiting to be used with jdk 1.5.0 update release. As soon as it will be verified, legally cleared and released, we are going to use it with JDK6 and 7.

            Idea is, to create a set of extended keycodes on startup of a user application. Thus the user will only operate with necessary set of keys, and there will be no need to invent and keep VK_ constants in KeyEvent for all possible national keyboards.
            Show
            yan Yuri Nesterenko added a comment - BT2:EVALUATION This is clearly RFE. Actually, we already have a solution based on a different keymapping paradigm waiting to be used with jdk 1.5.0 update release. As soon as it will be verified, legally cleared and released, we are going to use it with JDK6 and 7. Idea is, to create a set of extended keycodes on startup of a user application. Thus the user will only operate with necessary set of keys, and there will be no need to invent and keep VK_ constants in KeyEvent for all possible national keyboards.

              People

              • Assignee:
                yan Yuri Nesterenko
                Reporter:
                tyao Ting-Yun Ingrid Yao (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: