same path- different search times

Ask general questions here.
infproPemo
Posts: 4
Joined: Fri Sep 20, 2019 10:09 am

same path- different search times

Post by infproPemo » Mon Sep 23, 2019 8:14 am

I have a question regarding the time ranorex needs to find elements.

Why does it find some elements very fast one time, and then next time it needs significantly longer to find the exact same element in the same window with the same xpath?
My xpath is very specific and should be found quite fast every time. How can I fix this inconsistency?

Thank you
Best regards

User avatar
Stub
Posts: 277
Joined: Fri Jul 15, 2016 1:35 pm

Re: same path- different search times

Post by Stub » Mon Sep 23, 2019 8:18 am

Is it slow the first time you start your tests, and fast subsequently when it uses the cached item? However, you do mention fast then slow.

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 5459
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: same path- different search times

Post by odklizec » Mon Sep 23, 2019 8:28 am

Hi,

Could you please post a Ranorex snapshot (NOT screenshot) of the problematic element and the xpath behind it? Thanks.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

infproPemo
Posts: 4
Joined: Fri Sep 20, 2019 10:09 am

Re: same path- different search times

Post by infproPemo » Tue Sep 24, 2019 6:50 am

This is the xpath of the problematic dialog: /form[@title='titleofElement' and @actualwidth=806]
I use the width as second parameter, because there is another dialog that has the same title, but is maximized by default.

And this is the path of the first element needed within this dialog:
/form[@title='titleofElement' and @actualwidth=806]/?/container[@automationid='LayoutRoot']/text[1]/text[1]

the 2 text elements at the end do not have any unique identifier or title, so I have to access them through their row numbering.
the ranorex snapshot of this element is in appendex.

@Stub: Yes, the first time it works very fast, takes only a view seconds for the elements in the new dialog to be found, but after that, the same process will take several minutes to be finished.

Thanks for your help
Attachments
CM_MetadataDialog.rxsnp
(481.09 KiB) Downloaded 2 times

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 5459
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: same path- different search times

Post by odklizec » Tue Sep 24, 2019 7:29 am

Hi,

At first, please update Ranorex with most recent version 9.1.2! Version 9.0.0, which you are using now, is somewhat obsolete and to be quite honest, it contains some critical bugs ;)

At next, have you tried to add the AUT process name to Ranorex white list? Whitelisting of AUT process should noticeably improve the element search speed!

At finally, you can significantly improve the xpaths with input labels, like this:
//text[@automationid='textBlock' and @text='Name:']/preceding-sibling::text[@visible='true' and (@type~'TextBoxView' or @type~'TextBlock')]

//text[@automationid='textBlock' and @text='Standardwert:']/preceding-sibling::text[@visible='true' and (@type~'TextBoxView' or @type~'TextBlock')]
You see, each element has a label, which can be used for unique identification of each input. Using element indexes is something I would suggest to avoid at all costs, especially if there is a much more elegant solution ;) Hope this helps?
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

infproPemo
Posts: 4
Joined: Fri Sep 20, 2019 10:09 am

Re: same path- different search times

Post by infproPemo » Tue Sep 24, 2019 7:57 am

Alright, I found the solution.

The problem is the ranorex cache. It extremly slows down the process of finding this element .
I switched it off for this specific parent folder, and now it works out perfectly fine and with a consistent speed.