Window handles from process handles

[Zukie]

Given a process handle (or process ID) I can enumerate all of the top-level windows (using EnumWindows) and see which ones belong to that process. But how can I determine which one is "the" top-level window. For example, I have an application which has over 30 top-level windows associated with it and I can't always rely on the window title having identifiable text in it. Does anybody know how to solve this problem?

Thanks in advance for your help.

[Stevie-O]

What do you mean 'the' top-level window? As you said yourself, they're all top-level windows.

[Zukie]

Here's an example...

I use the application TextPad for my text editing. I've written a control to bring TextPad to the foreground maximized. One way to do this is to search all windows using EnumWindows. I can check the window titles to see which one begins with the substring "TextPad" and, using DLL injection, force it to the foreground in a maximized state.

I want this control to be able to do this when given a process ID as well as a window title substring. This is because some applications will not have a consistent substring in its window title for me to key on.

For TextPad, there are over 30 top-level windows for this application...for scroll bar, combo boxes, buttons, etc. I can switch any of them that I like to the foreground but I really only want the one that would be maximized when the user clicks on the minimized application in the taskbar.

Actually, I think I'm on the verge of the solution, namely, use class name. Does this seem correct to you?

Thanks for your interest.

[Stevie-O]

[1] Well, to answer your *last* question, class name is usually good, unless you're working with a program written in VB (they all have the same classes)

[2] I've never heard of "DLL injection"...what is it?

[3]

For TextPad, there are over 30 top-level windows for this application...for scroll bar, combo boxes, buttons, etc. I can switch any of them that I like to the foreground but I really only want the one that would be maximized when the user clicks on the minimized application in the taskbar.

I have a baaaaaaaad feeling you have NO CLUE what a top level window is. Try looking at the taskbar. All the visible top-level windows, and only those windows, show up on the taskbar. (with a few exceptions). Scroll bars and combo boxes and buttons and other controls are NOT top-level windows, and I'd really like to know who told you they were, so I can kick his ass.

[Zukie]

2) DLL injection is forcing a DLL to be mapped into the address space of another process. Then you can run your code in this processes address space, (thus, can force a SetForegroundWindow). The technique is mentioned in "Win32 API Programming with VB" by Steven Roman (Chapter 11 & 20) as a way of forcing an application to the foreground. I've also seen the technique mentioned in Richter's book, but I was just skimming that one. Very dangerous, of course.

3) Probably just poor terminology on my part. I mean windows in an application with no parent. There are two window enumeration calls in the Win32 API; EnumWindows and EnumChildWindows. According to the Win32 API docs, EnumWindows uses a callback and "...enumerates all top-level windows on the screen by passing the handle to each window..." (http://msdn.microsoft.com/library/psdk/winui/windows_7wvn.htm). With the window handle I can determine which process owns the window (I already have the process ID and process handle of interest). One can see (I've verified this in my testing) that a process seems to have many "top-level" windows (that is, when I filter out the window handles whose process ID doesn't match the one I'm searching for, I still get many windows enumerated). These windows seem to be scroll bars and the like. Ofcourse, they are not on the taskbar, but they show up in the enumeration. I do not know why this occurs. I'm just looking for some way to reliably identify the one window handle I want to maximize.