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

java doesn't support typeahead

    Details

    • Subcomponent:
    • Resolved In Build:
      rc2
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Description

      oracle complains JDK doesn't support "typeahead",the problem is:
      in an event listner, user's wants to open a new window and assign
      focus to it. if this is succesful, after returning from the event listener,
      user expects the future key event he gets to be all targeted to the new window.

      see the code sample below, note as the API said you are only supposed to
      call requestFocus when the component is visible, it can't be called directly
      within the keyListener.

      because the native message thread might have post key event targeted to the
      old window at the same time this event listener is running. when the user
      returns from the key listener, he might still get key event targeted to the old
      focus window.

      this is problem is in both win32 and solaris.

      code sample:(i attached the full test code AWTDialog.java in attachment)

      in a keyListner...
                dialog1.addWindowListener(new WindowAdapter()
                {
                        public void windowOpened(WindowEvent e) {
                          System.out.println("window opened");
                          tf2.requestFocus();
                        }
                });
                dialog1.pack();
                dialog1.setVisible(true);


      --> note from hania
      AWT provides support for typeahead; that is, as a user is typing, if one of the
      characters typed results in a requestFocus call, then the subsequent characters
      will be delivered to the new focus owner. However, such typeahead support is
      limited to the case where the requestFocus can be issued as part of the
      processing of the key event that caused it to happen, and this is not always the
      case.

      For example, imagine the case where one of the typed characters causes a Dialog
      to popup, and all subsequent characters typed are meant for a field in the
      Dialog. The call to requestFocus for the field in the Dialog cannot be made at
      the time the Dialog is created, because requestFocus can only be called on
      components which are visible on the screen. Thus the only legal way to write
      code that pops up a Dialog and sets focus to one of its fields is to wait before
      making the requestFocus call for an asynchronous notification that the Dialog is
      visible. But then, the key events for keys typed after the key that popped up
      the Dialog, but before the notification event that the Dialog is visible (and
      thus the requestFocus call) will be targeted at the old component.


      This problem could be fixed by a client-side buffer that collected the
      intervening events into a buffer, and retargeted them once the real target was
      made visible. However, in order to do this, client code needs to be able to
      reset the target of a dispatched event, which it currently cannot do

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tmasunw Tao Ma (Inactive)
                Reporter:
                tmasunw Tao Ma (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: