This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tweaking default java.awt.Robot settings

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);;

    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);
      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
        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.


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

Steve McKay <>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]