Re: Tweaking default java.awt.Robot settings

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

Steve McKayâ wrote:
> 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.

Yes, I shouldn't have said useless.. maybe "hard to use" :-)  In Mauve we traded 
timing-independent reproducibility for test case simplicity.  I did try writing 
synchronized Robot-using tests but it was a) difficult, and b) invasive, in that 
it required overriding and modifying the behaviour of methods that were being 
tested.

> For example, we can block until a
> window is ready to process events with code like this (only half baked
> at this time):

Even after you've ensured that the frame has responded, subsequent checks will 
still need to be synchronized, since Robot calls are not synchronous.  Or is 
this the specific problem that was causing test failures for you before -- that 
frames take a long time to be ready to receive events on other runtimes (e.g. 
Wine)?  If that's the main problem then maybe a hybrid approach of synchronizing 
frame readiness, then assuming small delays for Robot method calls, is a better 
approach.  Otherwise the proposal is to rewrite every Robot-using test to be 
perfectly synchronous (fine by me, but a big job).

Tom