ControlGetPos, bug or unclear documentation

[binhnx]

In the document, it said that ControlGetPos will return the control's position relative to its window. But it always returns the control's position relative to its top-level window.

Let's say that you have a button $btn in a child window $hWndC in top-level window $hWndP, and using ControlGetPos. Although you pass the $hWndC as parameter, the function still return position relative to $hWndP. 

So, it's a expected behavior of this function? Or it's a 'bug' or something like that? 

If it's a 'feature', anyone think that it's need to change, like me? Or at least, may someone correct the document to avoid confusion.

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$hWndP = GUICreate("TEST")
$hWndC = GUICreate("TEST2", 100,100, 5, 5, BitOR($WS_BORDER, $WS_CHILD, $WS_VISIBLE), -1, $hWndP)
$btn = GUICtrlCreateButton("BTN", 10, 10, 60, 40)

Local $aPOS = ControlGetPos($hWndC, '', $btn)
For $i = 0 To 3
ConsoleWrite(@CRLF & $aPOS[$i])
Next
GUISetState(@SW_SHOW, $hWndP)


While Sleep(10)
Switch(GUIGetMsg())
Case -3
Exit
EndSwitch
WEnd

Edited March 23, 2014 by binhnx

[JohnOne]

Name those flags of child window.

[binhnx]

Edited. 

[JohnOne]

Tried adding Opt("WinSearchChildren", 1), no luck.

Not sure it it's a feature or not but since it's just maths to determine your desired result, I'm unsure if it's a bug.

[LarsJ]

Have you tried these two functions:

_WinAPI_ClientToScreen
_WinAPI_ScreenToClient

[binhnx]

@JoshOne: I personaly also don't think it's a bug, but a strange behavior. 

@LarsJ: Sure, you can easily get the expected result using some lines of code.

So, should I fire a 'feature request' in Trac? And what should I fire? Modifying that function behavior or modifying the AutoIT document for that function?