-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
White is very slow to get elements in window #146
Comments
Why are you using RawElementBasedSearch? That is likely the source of your issues. From: guitardude89 [mailto:[email protected]] Hello,
I've also tried this way, and the results are pretty much exactly the same: Any way to speed this up??? They're always in a constant section of the screen, but exact pixel location will of course vary with the display. Thanks — |
Hi, Thanks for your response. I tried both with and without RawElementBasedSearch, and the time it takes is very similar - between 26 and 28 seconds. Any other ideas? Thanks |
Does your application have a lot of elements? Does UIA Verify or Inspect have the same performance problems when exploring the application? From: guitardude89 [mailto:[email protected]] Hi, Thanks for your response. I tried both with and without RawElementBasedSearch, and the time it takes is very similar - between 26 and 28 seconds. Any other ideas? Thanks — |
It does have quite a few elements, quite a few panes with tabs and toolbars which have buttons on them and a few checkboxes. I've been using WinSpy++ and UISpy, nether have the performance issues, the elements are populated within a second or so. Neither does the System.Windows.Automation library directly (although I've tried to stay away from it since its a tad ugly). I'm en route to work at the moment but I'll send the Windows Automation code which I'm now trying instead (which doesn't exhibit the slow performance). Maybe I'm doing something wrong code-wise in White (I'm not a trained programmer). |
This is what appears to work with System.Windows.Automation:
|
In the code above, why do you have Also try removing the Finally, you can turn on more verbose logging with
|
Regarding:
This was a piece of test code that I ran just to see what would happen if I stored all elements in an array. I've just removed it and:
I've also removed the |
What is logged when your code runs? Use |
A lot of stuff shows up in the console. Is it saved to a file anywhere? |
No, but we use Castle's logging abstractions, so you can use another LoggerFactory to do whatever you want |
This should be fixed in the next (v0.12) release. Please reopen this if it still is slow. |
did you try to use Get() instead of GetElement() ? I see that you tried it with buttons, but what about tabs?
I expect it to prevent string comparison of ALL the controls and compare strings of only Tab elements, since type criteria is always inserted as first criteria. [ see SearchCriteria.AndControlType() ] OTOH there was indeed an issue about clicking controls which waits at least as long as "BusyTimeout" configuration before click, so decreasing that to 1000 can be a quick fix in that case. I hope it is among what Jake is referring as "should be fixed in 0.12" =) |
Yeah, the issue was that the Silverlight busy cursor had the same number as a normal cursor. Hopefully that fixes these slowdowns, they don't seem to affect everyone. |
Thanks for quick answer! The wait-before-click issue i mentioned was in WPF though, not Silverlight. Does it affect it too? |
You can grab the latest builds off the build server or build yourself. Build server is at http://teamcity.ginnivan.net, you can login as guest. The issue I mentioned affects WPF, it's normal cursor matched a silverlight busy cursor, so white was waiting internally. |
ok, that makes sense. will do, thanks! |
Hello,
Any help or pointers would be very helpful. I'm automating an engineering application, and am trying to push a few buttons on it with a view to speeding up some workflow.
White finds the main window in a fraction of a second - but any child members take forever (28 seconds).
Here's the code I'm using:
I've also tried this way, and the results are pretty much exactly the same:
Any way to speed this up??? They're always in a constant section of the screen, but exact pixel location will of course vary with the display.
Thanks
The text was updated successfully, but these errors were encountered: