From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11957 invoked by alias); 25 Sep 2007 18:57:01 -0000 Received: (qmail 11947 invoked by uid 22791); 25 Sep 2007 18:57:00 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Sep 2007 18:56:58 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id l8PIurbH021157 for ; Tue, 25 Sep 2007 19:56:53 +0100 Received: from wr-out-0506.google.com (wra70.prod.google.com [10.54.1.70]) by zps37.corp.google.com with ESMTP id l8PIuOSA031501 for ; Tue, 25 Sep 2007 11:56:52 -0700 Received: by wr-out-0506.google.com with SMTP id 70so695831wra for ; Tue, 25 Sep 2007 11:56:52 -0700 (PDT) Received: by 10.142.179.12 with SMTP id b12mr181419wff.1190746611642; Tue, 25 Sep 2007 11:56:51 -0700 (PDT) Received: by 10.70.39.13 with HTTP; Tue, 25 Sep 2007 11:56:51 -0700 (PDT) Message-ID: <4f2ee4520709251156yde57b65tbb97032939ac75e6@mail.gmail.com> Date: Tue, 25 Sep 2007 18:57:00 -0000 From: "=?UTF-8?Q?Steve_McKay=E2=98=84?=" To: "Thomas Fitzsimmons" Subject: Re: Tweaking default java.awt.Robot settings Cc: "David Herron" , mauve-discuss@sources.redhat.com In-Reply-To: <46F95466.7070700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4f2ee4520709241331o1a77379cudffb314dc1622914@mail.gmail.com> <46F8238C.8020606@sun.com> <46F95466.7070700@redhat.com> X-IsSubscribed: yes Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00030.txt.bz2 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