Printable View
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.
What do you mean 'the' top-level window? As you said yourself, they're all top-level windows.
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.
[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]
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.Quote:
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.
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.