WIN(all) handle bug

[anonymous]

Strange bug for almost all functions related to the search window.
If the window handle, for example 0x00110758, then the same window be found from 0x00000758 (LoWord)

It generates such bugs as:
WinExists('192.168.0.1 - WINDOW NOT EXISTS') - This CODE return TRUE and finds window handle 0x000000C0, but the original handle 0x003100C0

WinGetHandle ("192.txt - THIS WINDOW NOT REALY EXISTS") - this return not valid handle

#include <WinAPI.au3>
$h = WinGetHandle('[CLASS:SciTEWindow]')
ConsoleWrite('Handle 1: ' & $h & @CRLF)
$hLo = _WinAPI_LoWord($h)
ConsoleWrite('Handle 2: ' & WinGetHandle($hLo) & @CRLF)

Here function WinGetHandle return wrong result to.

Bug is not observed on x64 systems.

Autoit 3.3.10.0 - 3.3.x.x

[Jon]

Seems to be some weird quirk of the Windows API. Outside of autoit I can get a handle to a window
0x00960608 and yet IsWindow(0x608) seems to point to the same window. I can even get window text from the same windows using both handles.

[Jpm]

I don't know why you want to use only the low part of an handle

an handle is 32-bit under Autoit-32 and 64-bit under AutoIt-64

WinGetHandle is supposed to work with title/text.
Weird the low part is pointing to the same Windows just use the return vale as a whole

[jchd18]

Vaguely related:
​http://msdn.microsoft.com/fr-fr/library/office/bb687833%28v=office.15%29.aspx

[anonymous]

WinGetHandle is supposed to work with title/text.

OK. But why

WinExists("192.168.0.1 - WINDOW NOT EXISTS")

returns 1? I don't have window with title "192.168.0.1 - WINDOW NOT EXISTS" and can't find window with handle 0x000000C0 (tried to use WinList, _WinAPI_EnumWindows, _WinAPI_EnumChildWindows).
Or "192.168.0.1 - WINDOW NOT EXISTS" is not a string?

[BrewManNH]

It doesnt't return 1 for me, it returns 0x0000000000000000 with an @error set to 1. I used this code, modified from the help file example, which should be just as valid.

#include <MsgBoxConstants.au3>

Example()

Func Example()
	; Run Notepad
;~     Run("notepad.exe")

	; Wait 10 seconds for the Notepad window to appear.
;~     WinWait("[CLASS:Notepad]", "", 10)

	; Retrieve the handle of the Notepad window using the classname of Notepad.
	Local $hWnd = WinGetHandle("[CLASS:Notepad]")
	If @error Then
		ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $hWnd = ' & $hWnd & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
		ConsoleWrite(VarGetType($hWnd) & @CRLF)
		MsgBox($MB_SYSTEMMODAL, "", "An error occurred when trying to retrieve the window handle of Notepad.")
		Exit
	EndIf
	ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $hWnd = ' & $hWnd & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

	; Display the handle of the Notepad window.
	MsgBox($MB_SYSTEMMODAL, "", $hWnd)

	; Close the Notepad window using the handle returned by WinGetHandle.
	WinClose($hWnd)
EndFunc   ;==>Example

BTW, using WinExists instead of WinGetHandle returns 0 with an error of 0.

[anonymous]

Replying to BrewManNH:

It doesnt't return 1 for me, it returns 0x0000000000000000 with an @error set to 1. I used this code, modified from the help file example, which should be just as valid.
...
BTW, using WinExists instead of WinGetHandle returns 0 with an error of 0.

It looks like this bug is only in x86

[anonymous]

Win7 x86

v 3.3.8.x

MsgBox(0, "", WinExists("192.txt"))        ; 0
MsgBox(0, "", WinExists(0x000000C0))       ; 0
MsgBox(0, "", WinExists(HWnd(0x000000C0))) ; 1

v 3.3.10.x +

MsgBox(0, "", WinExists("192.txt"))        ; 1
MsgBox(0, "", WinExists(0x000000C0))       ; 1
MsgBox(0, "", WinExists(HWnd(0x000000C0))) ; 1

Which version works correctly?

[Jon]

Ok, something is wrong there. Let me run it through the debugger.

[Jon]

It looks like it was a change trancexx made in Dec 2011 that just missed the 3.3.8.0 release and is only now showing up.

The change was what to do when a window match didn't occur. Basically if a window match fails it tries to interpret passed strings as window handles and then tries again. Oddly "192.txt" messes up when it is forced to convert from a string into a handle and ends up evaluating as 192 or C0. And that happens to be a valid handle.

This will possibly cause false matches with any string window titles that start with numbers. I'll have to remove the change or improve the conversion so that these errors don't occur.

[Jon]

Fixed by revision [10556] in version: 3.3.13.14

[anonymous]

How about

MsgBox(0, "", HWnd("192.txt")) ; 0x000000C0
MsgBox(0, "", HWnd("log.txt")) ; 0x00000000