Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fix for #399-top_window() should work on minimized application #580

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix for #399-top_window() should work on minimized application #580

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion pywinauto/application.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1112,14 +1112,19 @@ def top_window(self):
raise AppNotConnected("Please use start or connect before trying "
"anything else")

only_visible_windows = True
timeout = Timings.window_find_timeout
while timeout >= 0:
windows = findwindows.find_elements(process=self.process,
backend=self.backend.name)
backend=self.backend.name,
visible_only=only_visible_windows)

if windows:
break
time.sleep(Timings.window_find_retry)
timeout -= Timings.window_find_retry
only_visible_windows ^= True
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bitwise operation on a bool variable looks a little bit strange. It seems the loop iterations are altered by True and False values. It looks like a lottery or stochastic algorithm. I'd prefer something more explicit and clear. One of my thoughts were to remove top_window() method at all because it adds a lot of confusion when real top window is changing. It returns WindowSpecification with the handle at some moment and re-usage of this specification confuses a lot.

I think this issue should be solved after we implement an ability to create child window specifications from wrapper object as a parent in search criteria. So that top_window() could return a wrapper object.

Another possible way is to have top_wrapper() and top_window() equivalent to .window(top_level_only=True, found_index=0). But for UIA backend the meaning of top window is different because top window can be a child of main form. So it can be backend specific and therefore removed from Application object which is backend agnostic.

What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per your comment, I see three possibilities:

  1. To remove top_window()
  2. Solve the issue after implementing a feature to create child window specifications using parent in search criteria
  3. Make the top_window backend specific and remove it from Application class.

IMO, decision has to be made based on the amount of time and effort needed. Is it worth the effort? If you ask me I would simply say we get rid of top_window in future releases as I never use top_window() in my tests for the same reasons you mentioned above.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think point (1) is not good for coming 0.6.6. The second way is the most preferable for me. For the third one it shouldn't be removed from Application, but may call or contain backend-specific parts inside. I don't think the third way is worth efforts.


else:
raise RuntimeError("No windows for that process could be found")

Expand Down