How Do I remove "control id" and "class" from the RxPaths : How To …

[tallahassee101]

I see Ranorex 3.05 has something with Editing Path weights. I was wondering if it would be possible to filter out all "controlid" and "class" fields? We don't use these at all as our accessibleName and accessibleValue fields are descriptive enough to distinguish the different items. Any help would be appreciated.

[Support Team]

Hi,

I see Ranorex 3.05 has something with Editing Path weights. I was wondering if it would be possible to filter out all "controlid" and "class" fields? We don't use these at all as our accessibleName and accessibleValue fields are descriptive enough to distinguish the different items. Any help would be appreciated.

To add those two rules to your RxWeight Rules. Just copy each rule to the clipboard and press the paste button inside the rules dialog. Then the rule will be added automatically.

Rule for Control ID:

<rule name="Control ID" enabled="True" capability="nativewindow" attribute="controlid" setweight="0" conditionsoperator="or">
  <condition source="self" attribute="class" match="^WindowsForms10.Window" negate="False"/>
</rule>

Rule for Class attribute:

<rule name="Class" enabled="True" capability="nativewindow" attribute="class" setweight="0" conditionsoperator="or">
  <condition source="self" attribute="class" match="^WindowsForms10.Window" negate="False"/>
</rule>

Regards,
Peter
Ranorex Team

[tallahassee101]

So I paste the XML into the dialog section and it creates two new rules called Class and Control Id. However upon tracking in my app I get an item's path:
/form[@title~'softwaretitle']/element[@controlid='59648']/container[@accessiblename='somename']

So I don't understand how this is still getting generated in my path if the control ID filter is set to 0?

[tallahassee101]

So the problem with our software was this line:
match="^WindowsForms10.Window"

Removing that causes your code to work, however now I am seeing the problem that if there are multiple /form/element items they will be named:

/form/element[1]
/form/element[2]

Is there a way to force this not to happen? Even if it causes multiple items to have non-unique paths the items this would happen for we never use. An example is our window pane we display in:
/form[@title~'softwaretitle']/element[1]/container[@accessiblename='RvView']

If I have an accessible item with container accessiblename == "RvView", then it is unique. I know there is not another one in my test. If there were I would want Ranorex to crash or throw some sort of error.

Any ideas?

Thanks for the help

[Support Team]

Hi,

Sorry about the rules I thought you have a WinForms application, therefore the condition.

Is there a way to force this not to happen?

Not really, but you can try to set the RanoreXPath generation tree search depth to "2". Maybe this help. You will find this in the settings dialog of Spy on the General Tab under Advanced.

Regards,
Peter
Ranorex Team

[tallahassee101]

Peter,

The path weights are starting to make more sense, however it seems as if there are pieces missing to this rule set. For instance if I pull up the toolbar "capability" there are no "attributes" to select from the drop down. Additionally I've added a rule for accessibility:
<rule name="AccessibleName" enabled="True" capability="accessible" attribute="accessiblename" setweight="200" conditionsoperator="or"/>

However this rule seems to have no affect on the toolbars. I also noticed there is no "capability" for an element, so I can't add rules for them either.

Increasing the generation tree search depth removed the [1],[2],etc problem from second level elements, however I need some way to name, control, or hide elements. Control IDs change in our program based on generation order, I was going to try naming the classes if it is possible to add a rule for elements?

[Support Team]

Hello,

the capability combobox should have a list of capabilities. There might be a problem with your installation, if it has not.

After giving a rule a name, after choosing a capability and an attribute of that capability and after giving this a weight,
you make conditions when the rule should be applied.

At the conditions you might not see the attributes, e.g. if you choose parent or top level (i.e. the application or web page). You should find out the attribute separately using the Spy. The Spy uses the element tree, while the rule dialog does not use it.

Regards,
Roland

[tallahassee101]

The next time I tried to add a rule for "combobox" it did have a list of attributes, however I noticed that the "tree" capability and "toolbar" capability do not have any attributes. This makes it really difficult to add rules for new items.

Also is there a way to add a rule for an "element" capability? I do not see this in the list.

[Support Team]

Hello,

the element is not a capability. Ranorex.Core.Element stands between the adapter class and the implementation. When you do {Ranorex bt="path"; bt.Text;} this internally does {bt.Element.GetAttributeValue("text");} to get the value from the implementation class (derived from FlavorElement).
Element furthermore is there to make up the element tree, which is used to create the RanoreXPath.

As to why toolbar and tree do not list attributes: they are not capabilities. When you look at them in the Spy you will see Accessible for toolbar and NativeWindow for tree. Use these capabilities instead.

Regards,
Roland
Ranorex Support Team

[tallahassee101]

This works better, however there are still times where it seems the weights are ignored. Sometimes on objects in the Ranorex Spy Tool the attribute will be in BOLD letters however the path will not include the attribute. Other times the attribute will be include when on a parent item such as:
/form/container[@caption='captionname']
However the container's child will return a path such as:
/form/container[3]/tree[@acccessiblename='treename']

The "container[3]" causes problems, I'm not understanding why it doesn't use "container[@caption='captionname']" on the child as it does on the parent.

[Support Team]

Hi,

This is a little bit strange, this shouldn't be the case.
What you can do is to increase the "RanoreXPath generation tree search depth" in the Spy settings, two would be a good value.
If this won't work we would need a Ranorex Snapshot of your application, if you don't know how you can create such a Snapshot please take a look at the following link.

Ragards,
Markus
Ranorex Support Team

[tallahassee101]

I believe we've shared our project with Ranorex Customer support before. I tried changing the tree search depth but that made no difference.

[Support Team]

Hi,

Can you give us a hint on which project you are working and when we should have received your project?

The "container[3]" causes problems, I'm not understanding why it doesn't use "container[@caption='captionname']" on the child as it does on the parent.

It could be that your solution has changed and that the path to the specific tree is no longer unique if Ranorex uses the "caption" attribute. Maybe there is another container with the same caption attribute or the same tree element at runtime?

Regards,
Markus
Ranorex Support Team