How do you find a child window within a toplevel window's complete tree?

How do you find a child window within a toplevel window's complete tree?
I want to know if I am reinventing the wheel here.

I've come up with a cool function while working on a new class, that finds any child window, by its text or classname, within a main window.
It searches through each layer first, before moving on to the next smaller branch, or layer of windows.

The call looks like this:

Code:

---

Dim swnd As Integer = SendClicks.GetHandle("Form1", "Start")

---

No matter where the window with the text "Start" is, the function will return the handle to it.

You can specify an index, in case more than one window matches the specification.

Code:

---

Dim swnd As Integer = SendClicks.GetHandle("Form1", "Start", "5" )

---

This will obtain the 5th window matching the "Start" string.
The index follows the layers, of branches.
It prefers the closest window to the main window.

If I understand you correctly ...

FindWindow
The FindWindow function retrieves the handle to the top-level window whose class name and window name match the specified strings. This function does not search child windows.

FindWindowEx
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.

After much thought, I've decided that indexing it that way is not a good idea.
I've now made it more explicit:

Code:

---

SendClicks.Send(SendClicks.GetHandle("Form1", "GroupBox1", "GroupBox2", "GroupBox3", "Start"), "l")

---

Oh hi HanneS!

Yeah, I've chosen those api, instead of GetWindow.

My question and class method, is about going through all windows to find the specification.
I have not seen any full examples of how to search through all children windows, and children's children etc. of a given parent.

Quote:

---

Originally Posted by TT(n)

I have not seen any full examples of how to search through all children windows, and children's children etc. of a given parent.

---

Then this project of yours will be great, and something I'd like to see :)

So do you prefer the single call?

Quote:

---

GetHandle("Form1", "Start")

---

Or

Code:

---

GetHandle("Form1", "GroupBox1", "GroupBox2", "GroupBox3", "Start")

---

In each example there would be many other nested windows, with matching text, or class names.
So I've made the GetChildWindow method, available which can be called manually:

Code:

---

        Dim cwnd As Integer = SendClicks.GetHandle("Form1", "GroupBox1")

        cwnd = SendClicks.GetChildWindow(cwnd, "GroupBox2", 3)
        cwnd = SendClicks.GetChildWindow(cwnd, "GroupBox3", 2)
        cwnd = SendClicks.GetChildWindow(cwnd, "Start", 4)
        SendClicks.Send(cwnd, "l")

---

Where we get the third child window matching the text "GroupBox2".
We also get the second child window within that window matching the text "GroupBox3".
And get the fourth start button within that window.
Left click in the center(default) of that window.
This works with class names too, and is the main reason for keeping a traditional index structure(Parent-Child), instead of (Ancestor-Child).
Although I like the uniqueness of the first way I mention.

Ive got some questions, but I cant remember now...

Well, the first way you mentioned is quite short, and will do the job, right ¿
So, IMHO, I think it's also a good idea to be able to implement both method one and method 2, Incase someone opts for the second method (which is a bit more "thorough").

Just one thing here, probably being silly...
I noticed that you get the first child window with "1", and the second with "2", don't you think it's a good idea to rather start counting from 0, because .NET is 0 based ¿

Thank you for your comments. :thumb:

Quote:

---

and will do the job, right ¿

---

It will do the job, but the index can be unreliable, and confusing to a developer, if there are many matching class names.
For example, one may have to put a larger index of 20, even though the number of matching child windows within a particular parent that they are looking at has less, ie 4.
Because the function looks through every layer first, instead of every branch outwards.
I've kept the code however, since it is pretty neat. There is another use for this. :)

I cant implement both easily, since the second parameter, is for an ancestory, while method 2 is looking for parenthood.

Quote:

---

Just one thing here, probably being silly...
I noticed that you get the first child window with "1", and the second with "2", don't you think it's a good idea to rather start counting from 0, because .NET is 0 based ¿

---

No I'm glad you brought it up.
I dont think the zeroth parmeter matters here.
I'd need a scenario that applies, to see what you mean.

I have had some bad experiences with .NET counting from zero.
You will notice that I dont conform to some of those rules, since I've found them shakey.
For example File IO, is super fast but sometimes under load will over, or under pad at zero or one.
It makes the index of the first and last line, + - 1.
The same file, works with regular operations:

Code:

---

FileOpen(1, "MyFile", OpenMode.Output, OpenAccess.Write, OpenShare.Shared)
 FileClose(1)

---

Come to think of it, the zeroth parmeter is none.

Code:

---

GetHandle()

---

Where all parameter are optional, and by default the return is the current foregroundwindow.


GetHandle(),also includes other API that return handles:

Code:

---

GetHandle("{GetDesktopWindow}")
GetHandle("{GetFocus}")
GetHandle("{GetTopWindow}")
GetHandle("{GetForegroundWindow}")
GetHandle("{GetActiveWindow}")
GetHandle("{GetAncestor}")
GetHandle("{GetParent}")
GetHandle("{ChildWindowFromPoint}")
GetHandle("{WindowFromPoint}")
GetHandle("{GetMenu}")

---

Where these API will apply to the current status, ie current cursor point, and foregroundwindow.

Oh okay I've re-re-read your post on counting from zero.
I misunderstood, because you indexed them wrong. I think.

The first child was "1", not having one from methodolgy 2(zero is one)
The second child was "3"
The third was "2"
The fourth was "4"
Then click the L button once.

They were meant to be somewhat random.
This clears it all up now.

If you'd like to take a sneak peek here is a recent update of the SendClickToWindow class.
I'm working on the menu strings now, so that a click on a menu item is similar. :wave:

Quote:

---

Originally Posted by TT(n)

They were meant to be somewhat random.
This clears it all up now.

---

OK.

I had a look at the sample :thumb:

I changed the text of one of the buttons, to Test, then had this in Button1_Click :

Code:

---

        Dim cwnd As Integer
        cwnd = SendClicks.GetHandle("Form1")
        cwnd = SendClicks.GetChildWindow(cwnd, "GroupBox1", 1)
        cwnd = SendClicks.GetChildWindow(cwnd, "GroupBox2", 1)
        cwnd = SendClicks.GetChildWindow(cwnd, "GroupBox3", 1)
        cwnd = SendClicks.GetChildWindow(cwnd, "Test", 1)
        SendClicks.Send(cwnd, "l")

---

Fine.

I added an event handler to the Test button :

Code:

---

    Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
        MessageBox.Show("Test")
    End Sub

---

What happened when I clicked the SendClicks button was, it did fire the event, and as such the MessageBox was shown, but, the mouse pointer was basically stuck on the Test Button, and wasn't moveable..

Did I do something wrong ¿ :)

Quote:

---

Did I do something wrong ¿

---

Ofcourse not.
The messagebox is showing up while keyboard/mouse input is blocked.
I'll see if I can fix that minor detail. ;)
I was aware of it, but since it's not finished...

Anyway Hannes, here is a simple fix.
Call:

Code:

---

    Dim t As New System.Threading.Thread(AddressOf BlockInput)

    Public Sub BlockInput()
        apiBlockInput(1)
        System.Threading.Thread.Sleep(GetSetDesktopRegistry(False).HungAppTimeout)
        apiBlockInput(0)
    End Sub

---

Instead of apiBlockInput(1). Then replace apiBlockInput(0), with t.Abort()