When enumerating windows using EnumWindows, I get hundreds of handles instead of one per open window on my desktop.
First of all, i am curious if this is the correct behavior.
Secondly, trying to get a difference between open windows before and after launching a process returns 15-20 new handles. I am wondering if there is a way to filter these based on some flag, i really need just the mainwindow handle.
Any ideas?
To get the main window of a process, use the Process.MainWindowHandle property.
To answer your question, you can see exactly what all of the handles are using Spy++.
In short, many applications will create hidden windows to run message loops.
You can filter within the enum callback by checking IsWindowVisible() & ignoring invisible system/message sink windows.
Related
I would like to obtain handle to notification window (balloon) using WinAPI. How can I do it, correctly?
Currently I found the solution by enumerating all windows using FindWindowEx function and then obtaining all windows that belongs to ShellExperienceHost.exe process. The operation is executed using GetWindowThreadProcessId API call.
After that we are limited to five windows and one of that window is notification window. But, the only parameter I can base on is window name. In this certain case it is "New notification". However, for my native language it is "Nowe powiadomienie". The application I am currently working on, needs to support multiple language. So, creating set with the names is not good options. Because, the code will be difficult to maintenance and can be depend on further changes in Windows.
I will be grateful for any help in this area.
I've been messing around with some code, to allow for getting the Window Handle of a running process, and the handles of all child objects within it - e.g. running it against calc.exe gives the hWnd of calc, plus the handle of each button, etc, which is all straight foward enough. Alongside this, I'm using ProcessWatcher to watch for specific processes launching.
Now, where I'm having issues, is figuring out if it's possible to subscribe in some way, to be notified of the creation / deletion of Window Handles.
The intention is to use the 'new' Window Handle to get details about the object, and compare it to a list of items that the application should be watching for, e.g. the application would be sitting waiting for the notepad.exe process to launch, once it sees this process, it knows it should be watching out for a new window being created titled 'Save As', that is someone related to the notepad.exe process.
At the moment, the only way I can think of would be via a timer, after a short period, enumerate all Window Handles manually, sorting through them for what I want, but I'd imagine this would be very resource hungry, and inefficient.
Thanks in advance...
I've been looking around for quite a while, and can't seem to find a good way to do this.
Basically I have a C# process using WPF (which has no visible window), that I need to handle WM_ events in (such as WM_CLOSE or WM_DESTROY for example; so that I can elegantly shutdown when a user chooses to log off or restart their machine).
There are a number of solutions I've seen out there that suggest using System.Windows.InteropServices to call AddHook and provide it a pointer to a function that then becomes the WndProc. The problem with this is, as far as I can tell, it depends on the window actually being visible (and in this case there is no window).
Another way that's suggested but doesn't work is to override the WndProc method of a WinForm, but this process has no visible forms or windows.
I've also found things referring to a Message-only Window. Some kind of invisible window that still receives WM_ events. From what I've seen, this is only available in a Microsoft.WindowsCE.Forms assembly. I added a reference to this assembly in my project and subclassed MessageWindow as indicated at: http://msdn.microsoft.com/en-us/library/microsoft.windowsce.forms.messagewindow.aspx but it still seems to not work. The breakpoints inside the WndProc are not being hit.
Any clue?
Think about what you are asking- if you don't have a window, how could your application receive a window message (considering that messages are sent to a window's handle).
That's like saying "how can I receive email without having an email address?"
Michael Entin covers windows' behavior during shutdown here.
I am 99% sure that all processes running in a user's session are automatically closed when the user logs off anyway, so this shouldn't be an issue. If you really must handle this window message, you can create a hidden window as per Any way to create a hidden main window in C#?
This may be a long short or not even possible but no harm in asking.
What I am trying to do is monitor an application for any new windows it creates in its MDI control. I have implemented hooking in C# and can capture the MDICREATE window message but because I need to get information about the window after is has been created the MDICREATE message isn't much help because at that stage the window hasn't been created in the other application yet.
Without going into to much detail I just need to be able to see when a new window has been created.
Is this possible?
Thanks
I'm not aware of another message that gets the info that you are looking for off hand. But if that message works for you, you could hook that message and then do another scan of the windows to find the one you are missing. You can enumerate the child windows of the parent window. Use Spy++ to see the exact window hierarchy.
If you can watch for a particular function call, I would use some kind of hooking library to grab that (EasyHook comes to mind).
You can hook the MDI create function (assuming there is one), watch for that, then inn your code, call the original and do any lookups using the returned value. You'll have access to the returned value and any parameters, so you should be able to get some info out of those.
Two options off the top of my head.
Hook the WM_MDIACTIVATE event, the first time the window is being activated, use a flag to determine the first time the window is being activated.
If you need to run your code after the WM_MDICREATE or WM_MDIACTIVATE, you can post a new custom message from one of these messages, which is then handled after these messages have completed. You then write your code to handle the custom message.
I am using SetWindowPos() to try and send Windows to back/front of the z-order.
It seems to work for the most part however I am noticing for certain windows it just won't work although the function will return success.
For example Window Task Manager seems to work perfectly fine but the other windows aren't responding properly to the function call.
Any insights into what may be happening? I know the information is sparse however I am not sure what to include.
Pretty much seems to work using SetForegroundWindow.
From what I could discern it seems that using SetWindowPos and setting a window to HWND_TOP will make it top of the z-order following the foreground window.
Meaning that once the foreground window is removed (minimized/closed) it will then be the next one at the TOP.
I too have hod problems with this across processes. This from the MS documentation:
To use SetWindowPos to bring a window to the top, the process that owns the window must have SetForegroundWindow permission.
might be the cause?