ContainerFixture#dialog(long timeout) and similar methods

[GoogleCodeExporter]

I am using version 1.0a3 of the FEST-Swing module.

I currently use Thread.sleep to synchronize with dialogs.
I have a problem guessing how long each operation is going to take.
WindowFinder is a step closer to a solution, but using it is problematic.
Using it brakes the fluency of the API.
It should be used only in drivers.

One solution would be to add synchronization in the fixtures themselves.
For example, you could add
    ContainerFixture#dialog(long timeout)
which could use WindowFinder to find the dialog.

In general, all methods returning fixtures for windows or dialogs and all
methods returning fixtures for components which create windows or dialogs
(like ContainerFixture's fileChooser) should have a variant accepting a
timeout.

Adding synchronization to fixtures seems reasonable as it is normal for the
user to wait for something to pop up while following a trajectory in the GUI.

Thanks,
Csabi

Original issue reported on code.google.com by csaba.ju...@gmail.com on 3 Jul 2008 at 2:37

[GoogleCodeExporter]

Hi!

Absolutely agreed.

i am using Pause.pause(...) ,and in my fixtures i have to do smthing like this:

    publicCustomFixture customFixture() {
        return new CustomFixture(robot, waitFor(matcher(CustomComp.class)));
    }

Where:

    public <C extends Component> C waitFor(final GenericTypeMatcher<C> m) {
        Pause.pause(new Condition("Showing on screen: " + m) {
            @Override
            public boolean test() {
                try {
                    return find(m).isShowing();
                } catch (Exception e) {
                    return false;
                }
            }
        });
        return find(m);
    }

Original comment by filim...@gmail.com on 4 Jul 2008 at 6:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,

In the initial post I've said that certain methods should have a variant which
accepts a timeout. I think that it would also make sense to make the variant 
which
doesn't accept a timeout to wait for a predefined time.

I've implemented the variants accepting a timeout and found that I didn't 
really use
the variants without the timeout anymore. This is because in a general use case 
the
accepted behavior of these methods is to wait for the dialog or window.

If the methods without the timeout argument would wait for a predefined time, 
this
default timeout could be configured just like the delay between events is 
configured
with void Settings#delayBetweenEvents(int).
The methods with a timeout argument would still be useful in special cases, 
when it
is known that a dialog or window could take more to appear.

Thanks,
Csabi

Original comment by csaba.ju...@gmail.com on 16 Sep 2008 at 1:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue migrated to http://jira.codehaus.org/browse/FEST-32

Original comment by Alex.Rui...@gmail.com on 4 Mar 2009 at 1:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Fixed. Please see log in JIRA's issues for details.

Original comment by Alex.Rui...@gmail.com on 21 May 2009 at 2:09

• Changed state: Fixed

[GoogleCodeExporter]

Thanks a lot Alex. Which log are you referring to?

Csabi

Original comment by csaba.ju...@gmail.com on 21 May 2009 at 8:20