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