Opened 13 years ago
Closed 11 years ago
#2181 closed Bug (Rejected)
WinWaitActive() doesn't necessarily return active window
| Reported by: | nf9b9d5ka4@… | Owned by: | |
|---|---|---|---|
| Milestone: | Component: | AutoIt | |
| Version: | 3.3.8.1 | Severity: | None |
| Keywords: | Cc: |
Description
It appears that if there are multiple windows that match the arguments to WinWaitActive() that the handle that is returned may or may not be the active window that caused the function to return.
The instance that I was encountering was that I was matching "[CLASS:Afx:400000:0]". It turned out that while that was the accurate class for the window I wanted to match, there were two other invisible windows (WinGetState=5) that the program had created with the same class, and it appeared that WinWaitActive() was apparently returning one of those instead of the one that was active. This is somewhat speculative, but it makes sense, and it definitely wasn't returning the correct window.
I've worked around this by following the WinWaitActive() call with a WinList() call and a loop that checks to see which of the windows is actually active. So far, it's working a lot better, which, again, supports my theory. But it is just a theory.
Attachments (0)
Change History (2)
comment:1 Changed 13 years ago by nf9b9d5ka4@…
comment:2 Changed 11 years ago by Jon
- Resolution set to Rejected
- Status changed from new to closed
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
Some discussion about this on the forum: http://www.autoitscript.com/forum/topic/139422-controlgetpos-works-matching-window-title-but-not-class/