__WinAPI_EnumWindowsChild() creates results in wrong sequence

[CBruce]

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

[Jpm]

Fixed by revision [7702] in version: 3.3.9.5