Unable to scroll and change the values in Form which are not visible to Windowtester.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a Form widget in the composite. 
2. Form contains lots of fields like Radio button and Text Field etc.
3. Try to change the values of the fields which are not visible to the 
WindoTester.
4. WindowTester is not Scrolling to the point and not able to change the values 
of those fields.

My Form looks like --
Location: 
//Shell/-1//Composite/5//Composite/0//Composite/32//Composite/0//Composite/0//CT
abFolder/0//Composite/1//Composite/0//ScrolledComposite/1//Composite/0//Composit
e/0//RadioPropertyWidget/1

Layout Information: 
RadioPropertyWidget {}
    Style: LEFT_TO_RIGHT 
    Layout Data: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
    Bounds: Rectangle {450, 0, 636, 67}

What is the expected output? What do you see instead?
It Is expected that WondowTester should scroll and change the values Which are 
not Visible.

What version of the product are you using? On what operating system?
Window 7,32 bit
I am using http://dl.google.com/eclipse/inst/windowtester/latest/3.6
Version of Window Tester

Please provide any additional information below.

Original issue reported on code.google.com by PawanGa...@gmail.com on 18 Feb 2013 at 5:13

Attachments:

• scrolling.png

[GoogleCodeExporter]

The same Problem exists with ScrolledComposites.
Apparently WT is able to locate the Widget outside the visible area, but a 
ui.click(ILocator) on that Widget will cause WT to perform a click outside of 
the Shell, which potentially affects other open applications.

Original comment by max.hohe...@gmail.com on 18 Mar 2013 at 3:41

[GoogleCodeExporter]

Added a test case for ScrolledComposites.

One approach could be to find out if a SWT control (eg. a button) is contained 
in a ScrolledComposite by iterating through it's parent elements. If it is, 
then the .show() method of ScrolledComposite could be used to make the control 
visible.

I tried it with a little hack for a single locator (ButtonLocator) and it 
worked, but a more general solution for all kinds of locators would be needed.

Original comment by fred.g...@googlemail.com on 19 Mar 2013 at 11:27

• Changed state: Accepted

Attachments:

• scrolledComposite_Test_patch2.txt

[GoogleCodeExporter]

I created a new handler that can be used with IUIContext.ensureThat(...) to 
address this issue.
Because the code iterates over all ancestors, to ensure that the given control 
is fully visible even with several ScrolledComposites in the hierarchy, it 
might be a bad idea to scroll every locator automatically. Though this is not 
consistent with the behavior i.e. in TreeViewers, at least in large 
applications it could slow down the tests significantly to always try scrolling 
automatically. If this is not the case, it should still be possible to use this 
handler without major changes.

@Fred, currently the handler needs a small workaround. Hopefully you can 
improve this (see comments).

See the discussion in the forum:
https://groups.google.com/forum/?fromgroups=#!topic/windowtester-pro/r1cfARlH6Fg

Original comment by max.hohe...@gmail.com on 29 Mar 2013 at 9:03

Attachments:

• ScrolledComposite_ConditionHandler.patch