id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
2335	__WinAPI_EnumWindowsChild() creates results in wrong sequence	CBruce	Jpm	"In the latest beta version, (and going back to at least the 3.3.7.20 version - I did not check previous), the WinAPI.au3 file has an error in the {{{__WinAPI_EnumWindowsChild()}}} internal function.  The error causes the function to build the results array in the wrong sequence.  Here is the function:

{{{
Func __WinAPI_EnumWindowsChild($hWnd, $fVisible = True)
	$hWnd = _WinAPI_GetWindow($hWnd, $__WINAPICONSTANT_GW_CHILD)
	While $hWnd <> 0
		If (Not $fVisible) Or _WinAPI_IsWindowVisible($hWnd) Then
			__WinAPI_EnumWindowsChild($hWnd, $fVisible)
			__WinAPI_EnumWindowsAdd($hWnd)
		EndIf
		$hWnd = _WinAPI_GetWindow($hWnd, $__WINAPICONSTANT_GW_HWNDNEXT)
	WEnd
EndFunc   ;==>__WinAPI_EnumWindowsChild
}}}

= BUG:
In the body of the function, {{{__WinAPI_EnumWindowsAdd($hWnd)}}} '''should be''' called '''__before__''' {{{__WinAPI_EnumWindowsChild($hWnd, $fVisible)}}}.

= DESCRIPTION:
Currently, on entry to the function, we begin enumerating the child windows of the parent we are coming from.  But, instead of adding our first level-1 child window to the output array at this time, we immediately recurse (inside the While Loop) in an attempt to find any of that level-1 window's level-2 children.  Our level-1 window does not get added to the output array until the recursed call pops back up -- at which point, that window's level-2 children (and any of their level-n children) have already been added to the output array -- causing our level-1 ''parent'' window to be added to the output array '''after''' its level-2 children in sequence.

I wouldn't care if this was the same sequence used by the core Windows' APIs -- but Windows outputs its enum results in the standard fashion of parent-first, followed by children.

Thanks,
CBruce"	Bug	closed	3.3.9.5	AutoIt	3.3.9.4	None	Fixed	winapi enumwindows