Re: Tweaking default java.awt.Robot settings

["Steve McKayâ" <smckay at google dot com>]

Hi Thomas,

> If Robot can't be counted on to do something within some time
> delay, is it also useless in non-test applications?

David's suggestion to use multi-threaded paradigms for dealing with
the issue seems pretty good to me. For example, we can block until a
window is ready to process events with code like this (only half baked
at this time):

// before running any tests

    // show the window
    f.setSize(200, 200);
    f.show();

    waitForWindow(); // blocks until the frame has responded to a
keypress events

  ....

  class myFrame extends Frame {

    public boolean keyDown(Event e, int i) {
      synchronized(lock) { // lock is some explicit lock object
        key = new Integer(e.key);
        lock.notify();
      }
      return super.keyDown(e, i);
    }
  }

  /**
   * Blocks until the frame has responded to a keypress event.
   */
  private void waitForWindow() {
    synchronized(lock) {
      while (key == null) {
        r.keyPress(32); // send a key press event
        r.keyRelease(32); // don't press the key forever
        try {

          // wait for a notify from the frame, or timeout in case the
          // window missed the keypress event entirely
          lock.wait(100);
        }
        catch (InterruptedException ie) {
          // interrupted, if key is still null, we'll try again
        }
      }
    }
  }

The obvious downside is you have to deal with all the pitfalls of
multi-threaded code everytime you write the code.

--steve

> I've always wondered how the TCK certified AWT and Swing functionality.  Does it
> use EventQueue-posting?
>
> Tom
>
>


-- 
Steve McKay <smckay@google.com>