Implement WindowSpecification.find_all() and .find() methods instead of .wrapper_object()

I was using WindowSpecification.child_window (singular) to find windows with great success. I cmae across a messy problem where it bombed because of an ambiguity (more than one window matching the criteria). Try as I might with print_control_identifiers() I could not find them, though in the end did. Cost me some time and energy mind you. And much of that would have been saved if rather than this bombing:

open_dialog = my_window.window(title_re=name, control_type="Pane")

with an Ambiguity, I could quickly and simply change it to:

open_dialog = my_window.windows(title_re=name, control_type="Pane")

And get the list to work with!

Which I have done the hard way, but racing down and replicating the call to find_elements. The thing that was bothering me and tool me some while to grasp was that parent= takes not a wrapped element but its element_info … and that find_element needs a parent and backend specified, the defaults being applied by things that call it. So as per its documentation, it’s low level and down and dirty 😉.

Now it turns out this software has some interest control structure, in that it has two identically named Panes one the parent of the other and the only differentiator I can find is the class_name of the element. Everything else appears identical bar the parent and children() properties. One it seems is a docking control, and the other the actual Pane (it being wrapped in a docking control that allows you to move it around and dock it in the interface).

Still, finding this duplicity would be MUCH easier if the above recommendation was in place, a simple way to move from a Ambiguity Exception to a returned list to examine. I need to do this now anyhow with find_elements to choose one of such a pair based on the relationship between them).

[vasily-v-ryabov]

Hi @pakal thanks for your interest! We’ve started some search criteria re-factoring here: https://github.com/vasily-v-ryabov/pywinauto/tree/dev_nd_issue_403_dbg so that class derived from ElementInfo has its static list of properties that are available for search. We have only 2 failing tests left before creating a PR.

I had no chance yet to prepare some document with pywinauto’s architecture overview. So the main principles include “consistency everywhere” which means the same property names as search keywords, for example. Also we’re thinking about configurability of new backends with their own lists of search properties/keywords. Cross-OS consistency is more complicated direction which we didn’t touch at all yet (might be interesting for Qt5 or other cross-OS apps).

@airelil is currently working on Linux backend="atspi" which contains fully ready classes Application, AtspiElementInfo and basic AtspiWrapper with some other wrappers (not full list of wrappers yet). So branch atspi is the main candidate for next major release with our general re-factorings.

My student @morphine43 is working on the general re-factorings and search speed optimizations, but it’s going not so fast (summer is just finished, hope to speed it up soon). Real code profiling wasn’t started yet. Among other ideas the plan for optimizations include:

• Benchmarking set of scenarios on really rich apps like iTunes on Windows which contains more than 3K elements. It hangs .dump_tree() method for several minutes at least.
• Using Python features like __slots__ static member to reduce memory footprint.
• Minimizing *ElementInfo classes interface as much as possible but keeping all necessary search properties.
• Improving best_match algorithm which seems to be quadratic. Making it at least O(n log (n)) would be a big deal.
• Methods wait and wait_not should look for element existence only. State of the element should be monitored by wrapper methods like .wait_visible(), .wait_enabled() etc. It will simplify wait()/find() method implementation.
• Creating WindowSpecification from wrapper object as a parent.
• We can continue the list. Just find all issues by label “recorder_critical”. And it’s not the full list probably.

Label “recorder_critical” means that I thought to make next major release with fully automatic UI recorder that produces pywinauto based script for all user actions with a GUI app. But this task is complicated and the guys working on it seem to be out recently. So I decided to prepare more basic things for the release. Early release for UI recorder is dangerous because quality and number of reports will overload us. Replying on many questions is already notable activity for the main library maintenance.

[bernd-wechner]

Thanks. No problems. Will look into the atspi branch when next I need this. I use pywinauto only sporadically for automation jobs and clearly haven’t been for a while.