JDK-4447559 : RFE: physical vs. logical keyboard translation
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2001-04-19
  • Updated: 2005-09-07
Related Reports
Relates :  
Relates :  
Description

Name: krC82822			Date: 04/19/2001


java -version 1.3

While using java.awt.Robot to enter Keyboard characters into a webpage (with
help from a Virtual Keyboard), I find that the Robot class takes only KeyCodes
as parameters for its keyPress() method. This becomes a stumbling block if you
want to do translate that Keyboard as you have to let the Robot class know the
keycode value.

      JButton button0 = new KeyButton();
      button0.setHorizontalTextPosition(JButton.CENTER);
      button0.setVerticalTextPosition(JButton.CENTER);
      Kb.put(button0, new KeyEvent(button0, KeyEvent.KEY_PRESSED,
             System.currentTimeMillis(), InputEvent.META_MASK,
             KeyEvent.VK_BACK_QUOTE));
      add(button0);
      .
      .
      .
      .

   class KeyButton extends JButton
   {
      public KeyButton()
      {
      }

      protected void processMouseEvent(MouseEvent e)
      {
         e.consume();
         KeyEvent keyEvent = (KeyEvent) Kb.get(e.getSource());
         if (keyEvent.getKeyCode() != KeyEvent.VK_SHIFT)
         {
            if (e.getID() == MouseEvent.MOUSE_PRESSED)
            {
               ((KeyButton) e.getSource()).setSelected(true);
            }
            else if (e.getID() == MouseEvent.MOUSE_RELEASED)
            {
               ((KeyButton) e.getSource()).setSelected(false);
            }

            if (e.getID() == MouseEvent.MOUSE_CLICKED)
            {
               if (keyEvent != null)
               {
                  /*
                   * This is where the problem lies. Since we give a
                   * specific keycode, it becomes difficult to do so
                   * while doing translations.
                   */
                  robot.keyPress(keyEvent.getKeyCode());
               }
            }
         }
      }
   }

--------

19 Apr 2001, eval1127@eng -- see also # 4347983
(Review ID: 121017) 
======================================================================

Comments
WORK AROUND Name: krC82822 Date: 04/19/2001 No work around that i know of. ====================================================================== The workaround is for the submitter to provide his own translation table from logical to physical keyboards for each locale. He should really be doing this anyway, since the graphics on the touch screen should match the input locale the user is accustomed to (e.g. a French keyboard layout for French users). eric.hawkes@eng 2001-05-23
23-05-2001

EVALUATION I don't really understand this report. What "translation" are they trying to do? I don't see any in the test case (which is incomplete). Incidentally, the if (keyEvent != null) is unnecessary, since the keyEvent variable was dereferenced above; if the keyEvent was null, an NPE would aleady have been thrown. I think this is a request for new functionality, but I don't really know what the submitter is requesting. Maybe support for translating keyChars to keyCodes? keyCodes to keyChars? Changing to an rfe, and setting to incomplete. Emailed the submitter for more information on April 19, 2001. eric.hawkes@eng 2001-04-19 I don't really understand this report. What "translation" are they trying to do? I don't see any in the test case (which is incomplete). Incidentally, the if (keyEvent != null) is unnecessary, since the keyEvent variable was dereferenced above; if the keyEvent was null, an NPE would aleady have been thrown. I think this is a request for new functionality, but I don't really know what the submitter is requesting. Maybe support for translating keyChars to keyCodes? keyCodes to keyChars? Changing to an rfe, and setting to incomplete. Emailed the submitter for more information on April 19, 2001. eric.hawkes@eng 2001-04-19 The submitter is writing an application which uses a touch screen rather than the standard mouse and keyboard input. The screen has a graphic of a keyboard. When a "key" is touched, the Robot is used to generate a native key event. The problem the submitter is seeing is that Java provides a logical keyboard mapping rather than a physical keyboard mapping. That is, when the Robot is told to press/release a key (such as the "q" key), a key event is generated that results in VK_Q, regardless of what the keyboard looks like. Consider a standard US qwerty keyboard. When you switch to the French input locale using this keyboard, pressing the key labeled "q" will generate an "a" (regardless of whether you are using Java or a native application). The submitter would like the robot to figure out what the labels on top of the keys say, and press the key with the desired label rather than the key that produces the requested keycode. (This is a slight exaggeration: actually, the submitter would like the robot to press the key in the location of the key that normally has a "q" on top of it on a qwerty keyboard). This is a native keyboard mapping. eric.hawkes@eng 2001-05-23
23-05-2001