Retreiving controls on web pages

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
dino2dino4dino
Posts: 2
Joined: Thu Feb 25, 2010 12:08 am

Retreiving controls on web pages

Post by dino2dino4dino » Thu Feb 25, 2010 12:20 am

Hello,

We are evaluating Ranorex 2.2 for testing of few asp pages inside our desktop app. I am having trouble retreiving controls and performing actions on them.

Though ranorex spy identifies the web page as dom objects following line throws element not found exception.

WebDocument webDocument = "/dom[@caption~'^iSsample\ Worksample\ Tools\ ::\ M']";

The web page is embedded inside a desktop client and is not actually opened in browser.

How should I try to get such controls?

Thanks

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Retreiving controls on web pages

Post by Support Team » Thu Feb 25, 2010 6:29 pm

dino2dino4dino wrote:Though ranorex spy identifies the web page as dom objects following line throws element not found exception.
If Ranorex Spy can identify the web page, you should be able to do the same in code. Please, check that the you have the right path (try to search for "/dom[@caption~'^iSsample\ Worksample\ Tools\ ::\ M']" in Ranorex Spy) and that the Main method of your application is marked with the STAThread attribute!

Regards,
Alex
Ranorex Support Team

dino2dino4dino
Posts: 2
Joined: Thu Feb 25, 2010 12:08 am

Re: Retreiving controls on web pages

Post by dino2dino4dino » Fri Feb 26, 2010 1:21 am

Hi Alex,

Thanks for the response.

Marking the thread as STAThread worked. Thanks.
However I am surprised by the API changes from ranorex 1.x.

Few general questions..

1. Can we dynamically know the ranorex xpath at run time? Earlier for the controls when we had control ids, we used to store them all. But the xpaths seem to be pretty longer and not consistent (ofcourse based on GUI). But do we have to store all the xpahts?

2. How better is using xpaths?

3. In my web page, even though I see a button, ranorex threw a CapabilityNotSupportedException and I could access the control only as a InputTag. Is this expected? why is it referred as input tag in preferred capability instead of a button?

4. Can we store and use the name of the controls instead of the xpaths? Like GLOBAL_EDExamIndicatorValue and InputTagButton_Save?
So Like control id, can I store this control name and look for its value/details in the form?
If yes,could u give me some quick sample code?

Please let me know.

Thanks

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Retreiving controls on web pages

Post by Support Team » Mon Mar 01, 2010 2:01 pm

dino2dino4dino wrote:1. Can we dynamically know the ranorex xpath at run time? Earlier for the controls when we had control ids, we used to store them all. But the xpaths seem to be pretty longer and not consistent (ofcourse based on GUI). But do we have to store all the xpahts?
You can use the RanoreXPath dynamically too. So you need not to work with full path expressions. The Ranorex 2.0 API supports find methods quite similar to API V1.x. Also when working with Ranorex Repository you need not to use the complete path. You can shorten them manually. So within a form which is specified through an application folder within the repository (“/form[@title=’Calculator’]”) you can search for an item within it like that:
.//button[@controlID=’125’]
In fact, it is not required to specify each layer between.
dino2dino4dino wrote:2. How better is using xpaths?
With Ranorex 1.x it was necessary to step through the UI structure using the find method and check the conditions for the individual elements using code. With 2.x you can search for items using only one line of code. The path can be used as a way to serch for multiple items, too. So for example you can search with one path for items within a grid which have a checkbox value set to true...
In fact, you can still walk the element structure by writing code and check element properties to find the right elements, but RanoreXPath facilitates element identification.
dino2dino4dino wrote:3. In my web page, even though I see a button, ranorex threw a CapabilityNotSupportedException and I could access the control only as a InputTag. Is this expected? why is it referred as input tag in preferred capability instead of a button?
Web pages, or HTML sites, do not really have buttons. Therefore the preferred capability ‘InputTag’ is by design.
dino2dino4dino wrote:4. Can we store and use the name of the controls instead of the xpaths? Like GLOBAL_EDExamIndicatorValue and InputTagButton_Save?
So Like control id, can I store this control name and look for its value/details in the form?
If yes,could u give me some quick sample code?
I’m sorry, but RanoreXPath is always required. You can use it like that:
Ranorex.Form myForm = Host.Local.FindSingle<Ranorex.Form>("/form[@title='Calculator']");
Ranorex.Button myButton = myForm.FindSingle<Ranorex.Button>(".//button[@controlID='125']");
myButton.Click();
Please, consider reading the Ranorex Tutorial and the Ranorex User Guide, especially the section covering RanorexPath (http://www.ranorex.com/support/user-gui ... xpath.html).

Regards,
Christoph
Ranorex Support Team