BUG: TryFindSingle-Behavior

Bug reports.
Mark Klamt
Posts: 5
Joined: Tue Jul 30, 2013 2:13 pm

BUG: TryFindSingle-Behavior

Post by Mark Klamt » Thu Sep 19, 2013 9:37 am

Dear support team,

in our test solutions, we use the Host.Local.TryFindSingle method to validate if elements exist or are visible.
In some cases, we want to make sure that an Element does NOT already exist, but just using the method the way you describe in the tutorial does not work (reference: forcing a test case to fail).

What happens instead of just returning false and continuing code execution is the following: Ranorex is not waiting for the specified time (in this case a Duration of 10000, which is 10s), but for the whole interior timeout, which seems to be set to 1 minute, then finding that the element does not exist and directly throwing an exception and logging the error in the report, leading to abortion of test case execution even if the result is what we expected.

Current Ranorex Version used is 4.1, but the problem occurred with 3.2, too. Please check if you can fix this issue. I'd be glad if you can tell me a possible workaround because it is a critical feature we depend on in all our test projects.

Kind regards,

User avatar
Support Team
Site Admin
Site Admin
Posts: 12169
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA

Re: BUG: TryFindSingle-Behavior

Post by Support Team » Fri Sep 20, 2013 3:27 pm

Hello Mark,

Unfortunately I cannot reproduce the issue.
Could you please give me more information about the issue please? Do you mean that in your case the "TryFindSingle<Ranorex.Cell>()" method leads to an exception?
If you want to check if an element does not exist I would recommend to use the method Validate.NotExists() as described below.
bool notFound = Validate.NotExists("/form//table/row/cell[3]", 2000, "Searching for element", false);
Thank you!


Mark Klamt
Posts: 5
Joined: Tue Jul 30, 2013 2:13 pm

Re: BUG: TryFindSingle-Behavior

Post by Mark Klamt » Mon Sep 23, 2013 11:36 am

Hi Bernhard,

thanks for the hint, but even this call does not work. The code I use is the following:
bool notFound = Validate.NotExists(MainViewRepository.Instance.ExplorerControl.GetPath().ToResolvedString(), Validator.ELEMENT_SEARCH_TIMEOUT, "Searching for explorer", false);
if (notFound)
	//do something
	//return error message
If this code is executed, I get the following error. This happens either way (Validate.NotExist or the TryFindSingle approach) (see attachment).

Perhaps there is some setting I did not cover yet, but I can't figure out until now. Help is appreciated.

Kind regards,

edit: The code was wrong when it comes to the output of the NotExist-Method (as it was changed from TryFindSingle). I corrected it, but it does not change the error behavior since the whole if/else statement is not executed.
Output of Ranorex Report
logerror.png (6.44 KiB) Viewed 1418 times

Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: BUG: TryFindSingle-Behavior

Post by krstcs » Tue Sep 24, 2013 1:45 pm

You can't use the repository object to try to check for the repository object. That is a circular reference.

You are getting the error because Ranorex attempts to find the object when you use the reference and it can't find it.

This is Ranorex is doing for the line you are using...
1. Resolve MainViewRepository
2. Resolve MainViewRepository.Instance
3. Resolve MainViewRepository.Instance.ExplorerControl --- THIS IS FAILING because it can't find the actual ExplorerControl here, so it never gets to 4...
4. Execute GetPath() on MainViewRepository.Instance.ExplorerControl
5. Execute ToResolvedString() on path returned in 4
6. Execute Validate.NotExists() using 5, etc.

You will need to use the "INFO" object, not the actual object. You should have an ExplorerControlInfo or ExplorerControl.SelfInfo, depending on how you have your repo structured, which then has a "Path" property which you can use. It will return the path of the repository object without trying to find the actual object first.
Shortcuts usually aren't...