xpath relationship operator to return an HTML cell, based of cell found in row and column
Currently, there is no way to define an xpath, which would return a cell, based of cell found in HTML row and given table column.
Here is an example of simple HTML table:
<!DOCTYPE html>
<html>
<body>
<table style="width:100%">
<tr>
<td>ID</td>
<td>Col_A</td>
<td>Col_B</td>
<td>Col_C</td>
</tr>
<tr>
<td>ABC123</td>
<td>3</td>
<td>2</td>
<td>1</td>
</tr>
<tr>
<td>CDE456</td>
<td>11</td>
<td>22</td>
<td>33</td>
</tr>
</table>
</body>
</html>
Now let's say, I want to define an xpath, which would return a value from column "Col_B", but only from the row, in which is found cell value "CDE456". Something like this is currently not possible with single xpath.
There are two workarounds, the one involving custom code (FindSingle and GetAttributeValue) and the other one using recording module and GetValue action, which gets ChildIndex value from a repo element pointing to certain 'column' cell. The ChildIndex is then stored in variable and used in xpath like this:
/dom[@domain='www.w3schools.com' and @caption='Tryit Editor v3.1']//iframe[#'iframeResult']/body/table//td[@innertext=$cellValue]/../td[@childindex=$colNumber]
Where $cellValue = CDE456 and $colNumber = 2, so the above xpath returns value 22. This is the solution I'm currently using in my tests, but there are two drawbacks...
1) The $colNumber variable is never bound and shows as 'unbound' in test suite view.
2) This solution requires separate definition of element/xpath just for the column header element.
Neither of this I really like to see in my tests ;) Hence I propose a new relationship operator (or something else) that would easily match a cell based of row-cell and column.
Pavel Kudrys
shared this idea
Thank you for your input.
The problem here is that everything in Ranorex evolves around a “tree” view. All GUI elements have a specific place within that tree, and a cell in a specific row and column would require two “parent” elements, which just isn’t allowed within our framework. Changing this behavior would mean to make significant changes in the Ranorex Core.
We can only suggest to use workarounds like the /.. operator here, which should get you to similar results.
Best Regards,
The Ranorex Product Management Team