issues with WinGetPos function

[v1rtu0s1ty]

AutoItSetOption("WinTitleMatchMode", 4)

If WinExists("classname=rek20006c0000002","") Then
   WinActivate("Rekon 2000")
   WinActivate("classname=rek20006c0000002")
   $Dimension = ControlGetPos("classname=rek20006c000000", "", "rek20006c0000002")
   If IsArray($Dimension) Then
      msgbox(0,"Dimensions", $Dimension[0] & ", " & $Dimension[1] & ", " & $Dimension[2] & ", " & $Dimension[3])
   Else
      MsgBox(0, "Error", "")
   EndIf
Endif

Edit:  Forgot Code Tags

<{POST_SNAPBACK}>

I know what you mean in your code. The reason I was getting the error is because, the search string classname is not being seen.

How come, it's still not seen?

[v1rtu0s1ty]

ControlGetPos("classname=rek20006c000000", "", "rek20006c0000002")

<{POST_SNAPBACK}>

I tried it and it still doesn't help. Reading the manual for ControlGetPos, it's expecting a controlID in the last parameter. However, we are supplying a classname. And also, AutoIT window info is not able to pull any control ID once I hover the mouse on that error window.

Any more ideas? I'm using AutoIT version 3

[SmOke_N]

Burrup helped when I was having problems only be able to identify parital Class Names with something like below.

AutoItSetOption("WinTitleMatchMode", 4)

$WinList = WinList()
   
For $i = 0 To $WinList[0][0]
   $Class = GetClassName($WinList[$i][1])
   If StringLeft($Class, 15) = "rek20006c000000" Then
   $childwindow = WinGetTitle($WinList[$i][1])
   Else
    MsgBox(0, "Error", "Wrong Class Name")
   EndIf
Next

WinActivate("Rekon 2000")
$Dimension = WinGetPos($childwindow)
msgbox(0,"Dimensions", $Dimension[0] & ", " & $Dimension[1] & ", " & $Dimension[2] & ", " & $Dimension[3])

Func GetClassName($hwnd)
   Local $ret = DllCall("user32.dll", "int", "GetClassName", "hwnd", $hwnd, "str", "", "int", 32768)
   If Not @error Then Return $ret[2]
EndFunc

Hope this one finally works.

Edit: Put the StringLeft in there anyway, just to be sure.

Edited July 28, 2005 by ronsrules

[v1rtu0s1ty]

Burrup helped when I was having problems only be able to identify parital Class Names with something like below.

AutoItSetOption("WinTitleMatchMode", 4)

$WinList = WinList()
   
For $i = 0 To $WinList[0][0]
   $Class = GetClassName($WinList[$i][1])
   If StringLeft($Class, 16) = "rek20006c0000002" Then
   $childwindow = WinGetTitle($WinList[$i][1])
   Else
    MsgBox(0, "Error", "Wrong Class Name")
   EndIf
Next

WinActivate("Rekon 2000")
$Dimension = WinGetPos($childwindow)
msgbox(0,"Dimensions", $Dimension[0] & ", " & $Dimension[1] & ", " & $Dimension[2] & ", " & $Dimension[3])

Func GetClassName($hwnd)
   Local $ret = DllCall("user32.dll", "int", "GetClassName", "hwnd", $hwnd, "str", "", "int", 32768)
   If Not @error Then Return $ret[2]
EndFunc

Hope this one finally works.

Edit:  Put the StringLeft in there anyway, just to be sure.

<{POST_SNAPBACK}>

The dimensions that were shown was for the parent window. The X,Y was -4, -4 and the width and height was 1032, 748. I've attached a screenshot.

Thanks for digging this out.

Any more ideas?

EDIT: I'm adding a text file attachment that contains the HANDLE and CLASSNAMES based from your winlist code.

handles_and_classnames.txt

Edited July 28, 2005 by v1rtu0s1ty

[v1rtu0s1ty]

Something is really wrong.

This is the latest code to really verify all the dimensions of the questioned classnames.

AutoItSetOption("WinTitleMatchMode", 4)

WinActivate("Rekon 2000")

$WinList = WinList()

For $i = 0 To $WinList[0][0]
   $Class = GetClassName($WinList[$i][1])
   If $Class = "rek20006c000000" or $Class = "rek20006c0000002"  Then
      $childwindow = WinGetTitle($WinList[$i][1])
      $Dimension = WinGetPos($childwindow)
      msgbox(0,"Dimensions", $Dimension[0] & ", " & $Dimension[1] & ", " & $Dimension[2] & ", " & $Dimension[3])
   EndIf
Next

Func GetClassName($hwnd)
   Local $ret = DllCall("user32.dll", "int", "GetClassName", "hwnd", $hwnd, "str", "", "int", 32768)
   If Not @error Then Return $ret[2]
EndFunc

Not one result got close to what I was expecting. Please see all the 4 screenshots. So can we consider this is a bug?

Thanks.

Edited July 29, 2005 by v1rtu0s1ty

[Valik]

Well, what do you expect us to do about it even if it is a bug? Without the specific application in question, we can't fix the bug any more than we can provide regular support which we are doing now.

I highly doubt its a bug. Its very likely that your inexperience and the complicated design of the application hasn't yielded the right combination to find the window properly. There's not really a way to slip a window past the code. Try playing with "WinSearchChildren" and see if that helps any.

[v1rtu0s1ty]

Well, what do you expect us to do about it even if it is a bug?  Without the specific application in question, we can't fix the bug any more than we can provide regular support which we are doing now. 

I highly doubt its a bug.  Its very likely that your inexperience and the complicated design of the application hasn't yielded the right combination to find the window properly.  There's not really a way to slip a window past the code.  Try playing with "WinSearchChildren" and see if that helps any.

<{POST_SNAPBACK}>

I'm sorry, I really didn't mean to tone that way. That's the problem of posting messages. Sure, I will look into what you have mentioned, WinSearchChildren.

Is there other way I can troubleshoot to facilitate patching?

Thanks again.

[v1rtu0s1ty]

btw, I just found another tool, autohotkey. I found a code from the help file

Loop
{
    Sleep, 100
    MouseGetPos, , , WhichWindow, WhichControl
    ControlGetPos, x, y, w, h, %WhichControl%, ahk_id %WhichWindow%
    ToolTip, %WhichControl%`nX=>%X%`tY=>%Y%`nW=>%W%`t=>%H%
}

And it's able to retrieve correct coordinates and dimensions.

However, I'm already use to the autoit coding, it's much simpler to understand. And also, I have spent a day learning and modifying Inolesence text reader in gui mode(aka OCR). I don't want to spend another day or 2 learning new language.

Please see attachment.

[buzz44]

Those are coordinates for a minimized window.  How positive are you guys that you don't have the window minimized when calling WinGetPos() or that its not finding another window? 

By the way, I know from experience that Diablo II in windowed mode will automatically minimize whenever it loses focus and obviously to run a script in full-screen mode, you have to alt+tab out which also minimizes it.  Unless you are inserting a sleep delay before the call to WinGetPos() or invoking it via a hotkey, you will not get the coordinates of the Diablo II window because it will be minimized.  That is not a bug.

v1rtu0s1ty, I suspect in your case that there are more than one window in the system with that classname and its finding a different one than you think it is.

I highly doubt there is a bug in AutoIt.

<{POST_SNAPBACK}>

Thanks for info about a minimized window's X and Y co-ordinates. And yes whenever I ran the the script D2 was always minimized, and when using the AutoIt Window Tool it stays on top of the D2 window and it doesn't get minimized.

I came across this ironically trying to prevent accidently clicking outside the D2 window and minimizing it by creating a simple script using the MouseTrap() function that is floating around.