ControlGetPos works matching window Title, but not Class

[wfaulk]

I have a piece of code that waits for a window to become active, then manipulates a particular control:

$swwin = WinWaitActive("Window Title")
$cpos = ControlGetPos($swwin, "", "[ID:177]")

If I match the window based on the title text, as shown above, it works fine. However, the window title is not always the same, so I wanted to move to matching the window class instead:

$swwin = WinWaitActive("[CLASS:Afx:400000:0]")
$cpos = ControlGetPos($swwin, "", "[ID:177]")

This does not work, but not in the way that you're expecting. The WinWaitActive() call matches and returns, but when I try to reference $cpos[0] later in the code, it claims that it's not an array variable, and if I check @error immediately after the ControlGetPos() call, it's set to 1.

Why would it work correctly with the window title, but not the window class? What debugging steps can I take to see what's going on?

Edited April 9, 2012 by wfaulk

[BrewManNH]

Check the return value of $swwin using both the title and the class and see if they match.

[wfaulk]

I will try that as soon as my application administrator unbreaks the application I'm trying to automate. :/

[wfaulk]

I put in this code:

$swwin = WinWaitActive("Window Title")
$swwinc = WinWaitActive("[CLASS:Afx:400000:0]")
If ($swwin <> $swwinc) Then
    MsgBox(1,"Fail","Fail")
Else
    MsgBox(1,"Match","Match")
EndIf

I got "Match".

Edited April 9, 2012 by wfaulk

[wfaulk]

And now it works. I wonder if it's something my application admin changed.

Regardless, nevermind.

Edited April 9, 2012 by wfaulk

[wfaulk]

Grr. Now it's back to failing again, and I can confirm that the window handles returned by the two calls to WinWaitActive() are not the same.

[BrewManNH]

Double check that the class for the window is actually CLASS:Afx:400000:0 and you're not getting a control handle instead.

[wfaulk]

I'm positive that that's the Window Class, at least as according to AutoIt v3 Window Info.

I'm also running WinFlash() against the two handles. The one selected by title shows the correct window. The one selected by class doesn't show any window, though it waits the appropriate amount of time before continuing as if it were flashing the taskbar.

Also, GetWinTitle() and GetWinText() are returning blank strings for the class-selected window handle.

As it turns out, some of the other open windows from the same program have similar classes: Afx:400000:0:0:0:24300c57 and Afx:400000:0:0:0:b6dd166f. I don't know if that might be relevant or not.

[JohnOne]

Try using Option WinTitleMatchMode 2 to get partial match of window.

[Blue_Drache]

I do it somewhat differently. If the window contains a unique title, I just nab the handle(s) early in the program. Then I just deal with handles only for the remainder of the script. It's how I had to work my AS400 Emulator automation script several years ago. I had up to 6 windows on screen with the same class, but each one had a different title.

$hwnd_EmuA = WinGetHandle("A - [80x24]", "")
$hwnd_EmuB = WinGetHandle("B - [80x24]", "")
$hwnd_EmuC = WinGetHandle("C - [80x24]", "")

{stuff goes here}

WinActivate($hwnd_EmuA)
If Not WinWaitActive($hwnd_EmuA, "", 30) Then
   ConsoleWrite("Error:  Timeout waiting for Emulator A to activate." & @CRLF)
   Exit(101)
EndIf

Edited April 9, 2012 by Blue_Drache

[wfaulk]

It is neither unique nor consistent.

[water]

Looks like its an "Microsoft Foundation Class (MFC)" application. When you search microsoft web site for "afx" you'll find something like this.

I'm not familiar with this kind of programming but when you search the forum for "MFC" you'll find some other users having problems.

Just my 0,02$

[Blue_Drache]

What about screen scraping the window? Is there some unique TEXT in the window that you can check against?

[wfaulk]

@water:

It looks like that MSDN article seems to indicate that this is a sloppily programmed MFC application, which seems to fit with my experience. I'll bet that there is a hidden window somewhere that has the same class. I'm going to have to find some other way to uniquely identify these windows. Perhaps there is some unique text in the window that I can match against, as Blue_Drache suggests.

[JohnOne]

Well you could use winlist() in cahoots with WingetState() to only get windows that are visible.

[Blue_Drache]

@wfaulk: Your program:

[wfaulk]

I ran WinList() against that class and found that there are two invisible windows with that class running all the time. I wonder if WinWaitActive() waits for a window matching that class to become active, but then doesn't necessarily return that active window.

I'm going to try using WinWaitActive() followed by a WinList() and WinGetState() to find the active one. If that turns out to be the problem, I'd consider that a bug.

[wfaulk]

This seems to work, but I'll have to live with it for a while to be more sure.

$swwin = 0
WinWaitActive("[CLASS:Afx:400000:0]")
$winlist = WinList("[CLASS:Afx:400000:0]")
For $i = 1 To $winlist[0][0]
  If BitAnd(WinGetState($winlist[$i][1]), 8) Then
   $swwin = $winlist[$i][1]
  EndIf
Next
If $swwin = 0 Then
  MsgBox(1, "Error", "Window active but not active?!?")
  Sleep(5000)
  ContinueLoop
EndIf

[wfaulk]

FWIW, I created a bug report:

http://www.autoitscript.com/trac/autoit/ticket/2181