i.vasilyev wrote:Are you doing a FindSingle on the host each time or have you stuck the application into a variable and doing a findsingle on that?
Yes, i'm doing FindSingle on the Host each time
Will try to use your example, but not sure that it will help me because looks like a problem with a form itself(too many elements are under that form)
We're really just grasping at straws without a snapshot, but I completely understand why you aren't able to provide it. What we're trying to do is force Ranorex to limit its search area. Odklizec has a lot more experience with Ranorex, so I need to defer to his knowledge on this. I don't know for sure that my suggestion would improve performance, but utilizing a repository with rooted folders *should*.
I've never tried threading a Ranorex test, but I've thought about it. I have no idea if any of this would be thread safe and I think there are better solutions, but I'm a sucker for the big guns to to speak. If I were going to try to thread this, I'd break the searches out into Tasks (System.Threading.Tasks.Task) using the factory. I'd waitall for the search tasks to complete then put the input the data back in the main thread. My main concern would be that trying to thread the actual data input might change the UI and cause the element to become stale.
If you do go this route, I'l love for you to post your code for future reference and I'd be extremely interested in your thoughts about how it worked.
To get you started here's some junk code I hacked together from another non-Ranorex project. I'm drastically more familiar with VB .net code, so I used some converters to get this into C#. I make no guarantee or warranty as to the suitability of said sample.
Task<Ranorex.Unknown>[] myTasks = new Task<Ranorex.Unknown>[1];
myTasks[1] == Task<Ranorex.Unknown>.Factory.StartNew(() =>
{
Ranorex.Unknown myElement;
Host.Local.TryFindSingle("/form", out myElement);
return myElement;
})