Opened 14 years ago
Closed 13 years ago
#2181 closed Bug (Rejected)
WinWaitActive() doesn't necessarily return active window
| Reported by: | 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 by , 14 years ago
comment:2 by , 13 years ago
| Resolution: | → Rejected |
|---|---|
| Status: | new → closed |

Some discussion about this on the forum: http://www.autoitscript.com/forum/topic/139422-controlgetpos-works-matching-window-title-but-not-class/