Modify

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#2820 closed Bug (Fixed)

WIN(all) handle bug

Reported by: anonymous Owned by: Jon
Milestone: 3.3.13.14 Component: AutoIt
Version: Other Severity: None
Keywords: Cc:

Description

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

Attachments (0)

Change History (11)

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by 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

comment:4 Changed 3 years ago by 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?

comment:5 follow-up: Changed 3 years ago by 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.

Last edited 3 years ago by BrewManNH (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 3 years ago by 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

comment:7 Changed 3 years ago by 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?

comment:8 Changed 3 years ago by Jon

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

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by Jon

  • Milestone set to 3.3.13.14
  • Owner set to Jon
  • Resolution set to Fixed
  • Status changed from new to closed

Fixed by revision [10556] in version: 3.3.13.14

comment:11 Changed 3 years ago by anonymous

How about

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

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jon.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.