Ranorex Forum

Hi there... Be default Ranorex has all timeouts set to 30 000 ms (application, rooted folder, item) which may be eventually a serious pain in the ass, when it comes to the decision to edit this defaults for instance to 10 000 ms - The project as a whole just won't update itself and you have to it yourself and manually. Is there any simple, hidden trick how to update my project in an instance - with one single click? Thanks

Hi,

What you can do is to open the *.rxrep file in a text editor and edit all "searchtimeout" lines. However, I would not recommend to make the search timeout shorter. You see, it will not make the search for elements faster and too short timeout may lead to many unexpected failures.

To be honest, to make the solution faster wasn't my ultimate goal at all. I think when you know the application personally you're making automation for, you can afford such interventions and save some time when you already know the test will fail in one way or another But thanks anyhow!

Well you may be right But I would personally shorten the search timeout only at specific places instead of doing it globally? Just my 2 cents

Just 1 more option which I use for elements that I need quick timeout for.

Timeout for repo elements comes from repo item properties Timeout parameter. I have quite many scnearios where a specific element exists in which there might be multiple results depending on the shown child repo element. For those I wouldn't really want a 30 second timeout for each parent repo element. For this reason I have created a branch in the repo where I have specificed a very short Timeout.

Tree example:

IE (30 sec timeout)
-Parent (30 sec timeout)
--ParentChild (30 sec timeout)
---Element (30 sec timeout) (Effective timeout 4x30 sec = 2 minutes)
IE_Timeout (0.1 sec timeout)
-Parent (0.1 sec timeout)
--ParentChild (0.1 sec timeout)
----Element (0.1 sec timeout) (Effective timeout 4x0.1 sec = 0.4 sec)

So I have the option to choose from either the normal repository element and a shortened timeout repo element. And you basically only need to add the elements there that need the short timeout, not copy the whole repo to another tree branch.

So my global setting will not change and will not affect any other logic in my test project.

Eventually, you can use Exists() method with wait timeout of your choice, so you don't have to use two repo elements or mess up with default search timeouts. But yes, this solution would require using User Code action/code modules.

odklizec wrote:Eventually, you can use Exists() method with wait timeout of your choice, so you don't have to use two repo elements or mess up with default search timeouts. But yes, this solution would require using User Code action/code modules.

That's true. I actually used the repo timeout logic i talked about earlier in my previous solution which had to validate multiple repo items inside a different item. So i did use the "WaitForExists" functionality for the first element but i needed just to check if the child element is there quickly and I somewhat came to that logic. The result triggered another method and if i had to check lets say a hundred cases like so in a test flow the timeout tended to accumulate a lot.

I haven't really used this logic after that in my other test projects though. But it's just a nifty trick to know if you work more around recording test rather than coding them.

Just to re-iterate what Pavel said:

Shortening the search timeouts will not make the test any faster!

All it will do is make your test FAIL faster, and give you headaches trying to figure out why it's failing now when it was passing before. Timing issues are the most common (by far) and frustrating issues you can deal with when doing automation.

It is highly advised NOT to make the timeouts shorter than the default.

And, if you need to check for existence of an element, then, again as Pavel said, you can use Exists() with a custom timeout parameter.