Ranorex Forum

Hi Guys,
I was feeling quite smug after I managed to get a large, sprawling test up and running, then I attempted to run it on a subtly different build and it all started to go wrong.

I think I've tracked it down to the (many) instances of @class= in paths like this:
container[@controlname='mainDockPanel']/container[@caption='' and @controltypename='DockWindow' and @class='WindowsForms10.Window.8.app.0.33c0d9d' and @instance='4']/container/form[@controlname='OutputForm' and @title='Build Output']/container/text[@controlname='m_titleLabel']

My issue is that I'm using Ranorex to run sanity checks before I check in builds on various branches, and the exact class name of my controls sometimes change slightly when I change some of my code. Is there a recommended way of keeping the repository robust? Is there any way to prevent the recorder from using certain attributes like the class? Are we just supposed to do this manually?

Cheers
-Tom

By default, Ranorex tries to uniquely identify every level in the RxPath, i.e. all ancestors of the actually identified element. In your example, the "container[@caption='' and @controltypename='DockWindow' and @class='WindowsForms10.Window.8.app.0.33c0d9d' and @instance='4']" element seems to be one that is hard to uniquely identify, most probably because there are a lot of those controls and none of those have a "ControlName" set. That's why Ranorex uses all the attributes it can find for this element to identify it.

An "easy" way to get rid of the "class" attribute is providing Ranorex with another attribute it can use to identify the element. In your example that can be done by assigning a control name for each DockWindow in your application.
Another way is an additional plugin (called AttributeWeightPlugin) that allows to disable the use of certain attributes. Please, see the following forum thread for more information:
http://www.ranorex.com/forum/how-to-sta ... html#p4245

Anyway, I added an entry to our bug database that the "class" attribute should not be used at all for Windows Forms controls. We will consider that issue for the next update.

Regards,
Alex
Ranorex Team

Thanks for the tips - I'll give your suggestions a try.

Purhapse the ideal solution is to not use the number on the end of the class? Or could you modify the algorithm that gets run when you search for the control to be slightly fuzzy?

I'm sure neither option is trivial and modifying the core funcitonality like this probably isn't that desirable, but is there any way you could add some kind of whole recording validation mode where it helps you deal with subtle changes? Purhapse something to search for missing paths and allow the user to find the element using Spy?

cheers
-Tom

deepblue wrote:Purhapse the ideal solution is to not use the number on the end of the class? Or could you modify the algorithm that gets run when you search for the control to be slightly fuzzy?

The search algorithm depends on the RanoreXPath specified, so we could change the Path generation to use regular expressions. However, in this case we will omit the "class" attribute completely in RxPaths generated for Windows Forms controls, since for WinForms elements there are always attributes that identify the element better than the "class" attribute.

deepblue wrote:...but is there any way you could add some kind of whole recording validation mode where it helps you deal with subtle changes? Purhapse something to search for missing paths and allow the user to find the element using Spy?

What we have in mind is letting the user specify that execution should be paused when an element cannot be found. You can then start up Ranorex Spy, search for the desired element, and update the RxPath accordingly. This is one of the features we like to include in version 3.X (currently under development).

Regards,
Alex
Ranorex Team