Any limitation on how "deep" you can walk controls

[aux_con]

Ok... my head hurts.

So here is the scenario... I'm writing a simple macro to check to see if a button is enabled. If yes... click it and log the transaction. If no log a "not ready transaction". I've done this before on a different control and it worked great. But now I'm having troubles after the 3rd time I try to get the control handle.

Here is my code:

//Set Focus
SetFocus>A Station



//Find the handle of the "Send" button

//Get handle of Options window
GetWindowHandle>A Station,hwndAStation
//Returns proper handle

//Get left pane handle (child of main window)
LibFunc>User32,FindWindowExA,hwndLeftPane,hwndAStation,0,WindowsForms10.Window.8.app.0.378734a,
//Returns proper handle

//Get control pane handle (page address controls)
LibFunc>User32,FindWindowExA,hwndPageControls,hwndLeftPane,0,WindowsForms10.Window.8.app.0.378734a,
//Returns proper handle

//Get button handle (send button)
LibFunc>User32,FindWindowExA,hwndBtnSend,hwndPageControls,0,WindowsForms10.BUTTON.app.0.378734a,Send
//Returns NOTHING!

//do stuff with handle for button in question

Basically everthing is working great until I try to get the last crontol handle. It keeps returning 0. I've tried many iterations but can't seem to get this to work...

For now I think I'll use the img lib functions to "see" if the button is enabled or disabled. I was hoping for a more graceful and efficient solution though.

Any help is greatly appreciated!
THANKS!

[Marcus Tettmar]

No, there's no limitation. These are Win32 API functions and you can call them as many times as you like. But make sure you have the hierarchy right and maybe you need to set the hwndChildAfter value - you have these all as zero, so the search will always begin with the first child window of hwndParent. So in your code you'll always return the first instance of a child control. Perhaps in some cases you don't want this - you may have more tha one matching control.

The FindWindowEx function retrieves the handle to a window whose class name and window name match the specified strings. The function searches child windows, beginning with the one following the given child window.

HWND FindWindowEx(

HWND hwndParent, // handle to parent window
HWND hwndChildAfter, // handle to a child window
LPCTSTR lpszClass, // pointer to class name
LPCTSTR lpszWindow // pointer to window name
);


Parameters

hwndParent

Identifies the parent window whose child windows are to be searched.
If hwndParent is NULL, the function uses the desktop window as the parent window. The function searches among windows that are child windows of the desktop.

hwndChildAfter

Identifies a child window. The search begins with the next child window in the Z order. hwndChildAfter must be a direct child window of hwndParent, not just a descendant window.
If hwndChildAfter is NULL, the search begins with the first child window of hwndParent.
Note that if both hwndParent and hwndChildAfter are NULL, the function searches all top-level windows.

lpszClass

Points to a null-terminated string that specifies the class name or is an atom that identifies the class-name string. If this parameter is an atom, it must be a global atom created by a previous call to the GlobalAddAtom function. The atom, a 16-bit value, must be placed in the low-order word of lpszClass; the high-order word must be zero.

lpszWindow

Points to a null-terminated string that specifies the window name (the window's title). If this parameter is NULL, all window names match.


Return Values

If the function succeeds, the return value is the handle to the window that has the specified class and window names.

P.S. - yes the image recognition approach is much easier! The beauty of the image recognition approach is that it is more analogous to how a human works.