Search TimeOut is not being set (seems like a bug)

Ranorex Spy, Recorder, and Studio.
carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

Search TimeOut is not being set (seems like a bug)

Post by carsonw » Thu May 01, 2014 11:52 pm

...I have a screenshot to further illustrate the problem.

Basically in the repository my search timeout is 30 seconds, the effective time out is 1.5 minutes.

I have a WaitForExists on the object which failed immediately.

I wrote the search timeout to the reporting log during run time... it reports the time out is 0ms.

Why is this?
search time out is not correct.jpg
search time out is not correct.jpg (166.44 KiB) Viewed 1396 times
Last edited by carsonw on Fri May 02, 2014 5:40 pm, edited 1 time in total.

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

Re: Search TimeOut is not being respected...

Post by krstcs » Fri May 02, 2014 1:38 pm

For rooted folders (which is what you are referencing here) SearchTimeout is stored in the folder's SearchTimeout attribute, not in the SelfInfo.SearchTimeout attribute. (Yeah, it's confusing. :D )

Also, you can use "repo" as shorthand for the current repository instance.

Use:

Code: Select all

repo.IncomingFunds.IncomingFundsToSet.SearchTimeout
Shortcuts usually aren't...

carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

Re: Search TimeOut is not being respected...

Post by carsonw » Fri May 02, 2014 5:16 pm

Interesting, and good to know - thanks!

carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

Re: Search TimeOut is not being respected...

Post by carsonw » Fri May 02, 2014 5:38 pm

Alright, having looked further at my code, I can't work around this due to the way we have to pass our data. It seems like a bug, or at least undesired behaviour, for the SearchTimeout not be stored in the self info of an object.

Essentially what we are doing is this - we have quite a few tbody objects that we deal with - think of them as a grid with line items in an order. You can set the number of line items, which will then increase the size of the grid (by adding more rows). However, this is sometimes instant, or sometimes takes several seconds to happen. There is nothing happening on the page to indicate that anything is happening, the page will just sit there and then, all of a sudden, there will be more rows.

We wrote a generic method to handle this, and we wanted the time out to search to be based on the repository object. Because the time out is not stored in the self info, we can't do that.

Here is a copy of the code that will hopefully illustrate the point further:

Here I call the method:

Code: Select all

Utilities.WaitForTableToLoad(RepoIncomingFunds.Instance.IncomingFunds.IncomingFundsToVerify.SelfInfo,
			                                 (_incomingTransaction.IncomingPayments.Count + 1));
You can see I'm passing in the repository object (RepoItemInfo)

And here's how we do the search:

Code: Select all

public static void WaitForTableToLoad(Ranorex.Core.Repository.RepoItemInfo table, int expectedNumberOfRows)
		{
			int timeout = 100;
			int currentRowCount = 0;
			do
			{				
				TBodyTag lineItemTable = Host.Local.FindSingle<TBodyTag>(table.AbsolutePath, table.SearchTimeout);
				currentRowCount = lineItemTable.FindChildren<TrTag>().Count;
				
				Delay.Milliseconds(100);
				timeout--;
			}while (currentRowCount != expectedNumberOfRows  && timeout > 0);
			
			if (timeout == 0)
			{
				throw new InternalTestException("The table had " + currentRowCount + " rows, and we expected " + expectedNumberOfRows);
			}
		}
We need the RepositoryItemInfo because we have to search for the repository item again in each loop to get the latest number of rows.

The only option I have for a time out, above, is the table.SearchTimeout. Unfortunately that refers to the timeout of the SelfInfo object, which never gets set (which I think is wrong).

We have to use a rooted folder, because the rooted folder represents a table grid, and it has child objects in the repository, so using a rooted folder is the only logical choice here.

Is there some specific reason the objects SelfInfo isn't set? If there isn't a compelling reason can it be fixed for the future? Seems like a trivial fix. Thanks :)

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Search TimeOut is not being set (seems like a bug)

Post by Support Team » Wed May 14, 2014 2:42 pm

Let's see, maybe I can shed some light on that issue or at least share the developers' thoughts behind the RepoGenBaseFolder and RepoItemInfo classes/objects.

Basically, there are folders and items in a repository. Items always have a RanoreXPath associated with them. Rooted and application folders also have a path, but the idea was to only use them as containers for items with the same path prefix.
So originally, you could not directly get an element (or RepoItemInfo object) for a rooted folder, since it was only a logical container. You needed to create a separate item with an empty ("same as base") RanoreXPath. To avoid that extra mile, we added the "Self" and "SelfInfo" repository properties for rooted folders, that return the element and info object for such a "same as base" item in the rooted folder.

Summing up, the RepoItemInfo object returned for a rooted folder "SelfInfo" property does not correspond to the folder itself, but to a "Self" item with empty RanoreXPath within the folder. Consequently, the timeout (default 0) and path (default empty) returned by the SelfInfo object are by design.

Changing that mechanism or allowing to set the folder timeout through the SelfInfo object would be a breaking we would rather avoid. Additionally, it may cause weird side effects since you would change the effective timeout of all items within the folder, not just the timeout for the folder Self element.

What you could do is extend your WaitForTableToLoad method and check for info objects with empty path. For such items, you could then use the ParentFolder property to get to the folder object and set the SearchTimeout there. Caution, this will change the effective timeout for all items within the folder!

A better alternative is probably change the method to use the CreateAdqapter method instead of a Host.Local.FindSingle. That will automatically use the repository structure and effective timeouts:
TBodyTag lineItemTable = table.CreateAdapter<TBodyTag>(true);
Regards,
Alex
Ranorex Team
.
Image

carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

Re: Search TimeOut is not being set (seems like a bug)

Post by carsonw » Tue Jul 08, 2014 6:34 pm

Hi Alex - appreciate your insights. One thing I wanted to make clear though - we're not looking to set the timeout in the code - we're just looking to get the timeout that has been explicitly set in the repository. It's just that we can't get it.

Since the Self / SelfInfo methods have been made available, I would argue then, that they should work in a predictable way. I don't think it's good practice to implement them, but then have them behave unpredictably in order to not break something seems kind of like a hack to me.

I could understand setting the SelfInfo Timeout may affect all child items, but that seems like a logical, expected change, if you understand how the repository structure works. I think if people are working on this low level you can probably trust them to understand this change - or at least ask for help if it doesn't make sense.

In short, the developers have caused the functionality to behave in an unpredictable / unpredictable (and undesired in our case) way... in order to avoid having unexpected / breaking consequences? That doesn't really make sense to me.

If you're going to make the Info Object available, then you make it properly available, not just partially in a way that nobody could predict or identify without seeking further support.

As for your suggestion with the CreateAdapter... we can give that a go. But I still wanted to put my two cents in - basically if you're going to let us treat the rooted folder like an Info object... then it should do so completely else it just makes things even more confusing. Thanks!

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Search TimeOut is not being set (seems like a bug)

Post by Support Team » Mon Jul 21, 2014 3:58 pm

carsonw wrote:In short, the developers have caused the functionality to behave in an unpredictable / unpredictable (and undesired in our case) way... in order to avoid having unexpected / breaking consequences? That doesn't really make sense to me.
Hmm, I guess you got me wrong. It's not that we meant to make a compromise between compatibility and usability with the Self/SelfInfo objects. The SelfInfo object was implemented to be consistent with the other *Info objects for repository items.

What the main point of confusion seems to be is that the SelfInfo object does not hold information about the folder it resides in, but it holds information about the Self object that is created for rooted folders. It just holds the path and timeout information relative to the containing folder, just like all the other *Info objects for repository items within the folder. Currently, folders do not have a RepoItemInfo object themselves, all the information about a folder is found in the RepoGenBaseFolder class.

If you look at the path and timeout information in RepoItemInfo objects, you will always get the relative information with respect to the containing parent folder. I.e. for the path and timeout, you only get the relative path from the parent folder and the timeout to search for the item relatively from parent folder.
So, when you look at a RepoItemInfo object from a RepoGenBaseFolder instance, IMHO the returned values should be consistent and logical for all info objects, including the SelfInfo (all information relative to parent folder).

However, I agree, if you just navigate through the RepoItemInfo hierarchy using the Children property, the information for SelfInfo items looks wrong (zero search timeout) with respect to the RepoItemInfo object having the SelfInfo as a child. I guess the only way around that would be to generate separate info objects for the folder and for the Self item, the folder info object returning the folder timeout and the SelfInfo object still returning zero. Would that make it clearer and easier to understand?

Regards,
Alex
Ranorex Team
.
Image