Index vs ControlID

[BeardMJ]

Hi All

When I use the Ranorex SPY tool to find a container it located it with a container ID (control ID), but then when I run the SUT it fails to find that component. I then change to INDEX and the container is found. Two questions:

What is the difference between INDEX and the Control ID of an element or component?

Why is it Ranorex can't find certain highlighted items? I.e. I index an item to 1 but the highlighted item in track is something totally different, or can't find what I want it to find.

The SUT is an Air traffic control strip system that is adapted very badly so I have to edit the XPath a lot.

Screenshots may help if required.

Regards

[Vaughan.Douglas]

It might be very helpful if you could upload a Snapshot of the objects for us to examine. In general the index is an instance indicator, so the first one will have an index = 1 and the second will be index = 2 so on and so forth. Index is NOT a very reliable means of object identification.

Your control ID or container ID sound like attributes of some kind or another. Is it possible that the container ID (control ID) value is dynamic? So when you identify it the first time the container ID (control ID) value is "1234" but when you run it again it's now "4321".

[BeardMJ]

Hi Douglas

I've enclosed a Snapshot and image of the issue.

Basically the SUT has 4 to 5 panes (elements) divided into bays (elements) and then I create a strip (container). Whats happening is a when I validate containerXXXX (the strip) ranorex allocates a containerID, ok no problems. But on some roles (SUT) I highlight the container and ranorex can't see it.

I then edit the XPATH so I drill down through the tree to the container, I was told by the ranorex tutor to use INDEX. Which I did and for some for some of the roles this worked, but for others Ranorex will say "4 elements highlighted" but it's not the one I need and I can't index it.

I've enclosed a snapshot with an example container I can't locate with the INDEX and as you said when the system starts up again the controlID changes and Ranorex can't find the element or container anymore. How do I get around this without the Index?

Regards

[odklizec]

Thanks for the snapshot. Please post also an example of failing xpath, which was correctly recorded and now it does not work.

Unfortunately, after checking the snapshot, I have to say that your app (its GUI) is extremely automation unfriendly. Ideally, you should be able to use ControlIds to identify the controls. But ControlIds in your app are most probably not persistent and therefore not suitable for identification purposes. And because there are virtually no texts or other usable identification attributes, your only hope seems to be using indexes. Sadly, indexes are fragile and not reliable in a long run. So you will most probably have to update them from time to time.

The only other thing that you might probably try is GDI Capture List, as described here:
https://www.ranorex.com/support/user-gu ... tions.html
But due to the lack of texts in your app, I would not put much hope into this solution.

[BeardMJ]

Hi

Thanks for looking.

Its never worked that's the issue, literally when I record and then highlight Ranorex can't even locate it.

As you said the SUT is very difficult to automate because its not object oriented in its development so grabbing images is difficult because it can't drill down too far.

[Vaughan.Douglas]

Fear not, all is not lost, I'm a sucker for hard cases.

Can you provide two new snap shots of identical elements so we can see how they change. We've got a few different classes that will give us a place to start. They grey "header" things appear to have an AccessibleRole of "dialog" which may also be helpful when trying to use the GDI Capture technique.

The thing with these containers is that we need to figure out how to get inside of them. You could try grabbing snapshots of the containers to see if that helps drill down.

Code: Select all

//container[@accessiblerole='Dialog']

[BeardMJ]

Hi douglas

Please see the two attached Elements which are the same but generate different IDs.

why does Ranorex identify them differently, because the way in which the SUT is built?

[Vaughan.Douglas]

Hi douglas

Please see the two attached Elements which are the same but generate different IDs.

why does Ranorex identify them differently, because the way in which the SUT is built?

I'm going to give you some homework. If you're not familiar with Ranorex Path (RxPath) or Xpath which RxPath is based on, you should become familiar. Read through the Ranorex guide on Ranorex Path and this blog about RxPath Tips and Tricks. I have a feeling this will help out a lot.

The two elements you've identified are NOT the same element, but they are the same kind of element. It's like seeing two identical cars on the street. They may be the same car on paper but they are distinct instances of the same concept.

The path

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']/element[@controlid='59648']//element[@controlid='100190872']

leads you to an "element" of class Afx:00400000:0:00010005:00000000:00000000 at a specific location whereas

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']/element[@controlid='59648']//element[@controlid='100193744']

goes to another instance of the same element (class Afx:00400000:0:00010005:00000000:00000000) at a difference location.

If you use the RxPath

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']//element[@class='Afx:00400000:0:00010005:00000000:00000000']

you'll see there are 7 instances of this same element, each with its own control ID.

When I compare the two new SnapShots you've provided with the original SnapShot it doesn't appear that the control IDs are actually changing. That's not to say they don't change with each new build, but I can only comment on what I'm seeing.

In all three cases the RxPath

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']/element[@controlid='59648']//element[@controlid='59649']

exists and each are a AfxMDIFrame100 class. The descendant hierarchy of that first example is radically different than the subsequent SnapShots, but I suspect that is because it's at a different step in your process. For example appending

Code: Select all

//element[@class='Afx:00400000:0:00010005:00000000:00000000']

to the end of that path yields 3 elements in the original snapshot and only two in the second set.

RxPath is a locator much like a file system on your computer. You may have a document called "Hello World" in two different directories. You can do a search in Windows for "Hello World.doc" and find them both, or you can use a path to locate the specific document at c:\Users\Document\Hello World.doc versus c:\Users\Username\Desktop\Hello World.doc. RxPath works in much the same way. Does this help?

Have you discovered how to highlight repository objects in the AUT but right clicking them in the repository? This might help you understand the relationships you describe with RxPath.

[BeardMJ]

Hi Douglas

Thanks for all this.

I am familiar with the XPATH as I've had to edit so many to pick up the INDEX of an element, but not the RxPATH.

When I right click to highlight the element it is no longer possible to see it.

I will have a read of the links provided.

Regards

[Vaughan.Douglas]

Hi Douglas

Thanks for all this.

I am familiar with the XPATH as I've had to edit so many to pick up the INDEX of an element, but not the RxPATH.

When I right click to highlight the element it is no longer possible to see it.

I will have a read of the links provided.

Regards

RxPath is short for RanorexPath which is the Ranorex team's object identification scheme. When you use the recording feature to add objects to the repository the RxPath may not be as robust as it could be. You can use many of the standard functionalities from vanilla xPath in RxPath such as axes. If you've got a specific RxPath you're having trouble with, post what you've got and snapshots containing the element and I'll try and help you. I'll need one snapshot of the element where the Ranorex identifies it and another where Ranorex is telling you it can no longer find it.

[BeardMJ]

Hi mate - I've read the blogs and it has helped.

My main issue is with the elements (above) that have the same location.

You say they are not the same , even though they are clicked as the same pane (same looking cars). I'm not sure whether I need to edit the XPath to find the class Afx:00400000:0:00010005:00000000:00000000 or the control ID.

Can you edit a location identifier?

The steps taken to get these are identical, open the same control sector and select the same area (pane).

[Vaughan.Douglas]

Hi mate - I've read the blogs and it has helped.

My main issue is with the elements (above) that have the same location.

You say they are not the same , even though they are clicked as the same pane (same looking cars). I'm not sure whether I need to edit the XPath to find the class Afx:00400000:0:00010005:00000000:00000000 or the control ID.

Can you edit a location identifier?

The steps taken to get these are identical, open the same control sector and select the same area (pane).

Just so I know we're speaking the same jargon, can you please clarify what you mean by location identifier? To me the location identifier is synonymous with RxPath.
Class and ControlID are just attributes and you can use both in your RxPath for the same element. Example:

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']//element[@class='Afx:00400000:0:00010005:00000000:00000000' and @controlid='123456']

However in this particular case the Control ID attribute appears to be unique, so you wouldn't gain anything by specifying the class.

[BeardMJ]

Hi mate

Thanks again, its comparing the two elements I sent earlier. they are identically grabbed and tested but as you explained they are not the same.

I'm not 100% if its possible to drill down and reference them in the xPath.

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']//element[@class='Afx:00400000:0:00010005:00000000:00000000' and @controlid='123456']

It has the same Afx class_ID (to confirm this is the location identifier??) but the control ID isn't the same anymore. so when I edit the Xpath to include this it still fails.

Could I put the class_ID in the xPath and ignore the control ID?

[odklizec]

Hi,

I would suggest you to read this blog post about working with dynamic IDs...
https://www.ranorex.com/blog/automated- ... namic-ids/

What you need to do is to define a new weight rule, where you should increase the weight number for "class" attribute and reduce the weight number for "controlid" attribute. Next time you will track an element, the "controlid" will be ignored and there should be used "class" attribute in the generated xpaths.

[Vaughan.Douglas]

Hi mate

Thanks again, its comparing the two elements I sent earlier. they are identically grabbed and tested but as you explained they are not the same.

I'm not 100% if its possible to drill down and reference them in the xPath.

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']//element[@class='Afx:00400000:0:00010005:00000000:00000000' and @controlid='123456']

It has the same Afx class_ID (to confirm this is the location identifier??) but the control ID isn't the same anymore. so when I edit the Xpath to include this it still fails.

Could I put the class_ID in the xPath and ignore the control ID?

Class and ControlId are just two of many attributes. You can use any attribute you'd like, but you're end goal is to uniquely identify one element from all the others.

2017-06-28_9-24-56.png

So the RxPath

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']//element[@controlid='100190872']

and

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']/element[@class='AfxMDIFrame100']/element[@class='AfxFrameOrView100']/container[@class='#32770']/following-sibling::element[@class='Afx:00400000:0:00010005:00000000:00000000']

describe the same element.

The second one is longer because the Afx:00400000:0:00010005:00000000:00000000 class has several instances, and we're looking for a particular one.

So Root

Code: Select all

/form[@title~'^EXCDS\ LTC\ Workstation\ Ver']

child

Code: Select all

element[@class='AfxMDIFrame100']

child

Code: Select all

element[@class='AfxFrameOrView100']

child

Code: Select all

container[@class='#32770']

then FOLLOWING SIBLING

Code: Select all

following-sibling::element[@class='Afx:00400000:0:00010005:00000000:00000000']

We go from one node to the next like stepping stones across a stream. At each step (node) we describe the relationship between the current step and the next step. the single slash "\" says child whereas the double slash "\\" says any descendant. Following-sibling means that the target element shares a parent with the current element, it is further clarified that it's an element to the right (as the DOM is read left to right) of the current element.