I'm trying to pop notepad window in my c# Application using this code:
Process[] Processes = Process.GetProcessesByName("notepad");
IntPtr hWnd = IntPtr.Zero;
Debug.WriteLine("Processes: " + Processes.Length);
// do something
foreach(Process p in Processes)
{
Console.WriteLine(p.ProcessName);
SetForegroundWindow(p.Handle);
ShowWindow(p.Handle, ShowWindowEnum.Show);
//SetActiveWindow(p.Handle);
//p.Kill();
}
The console logs "notepad" just fine. I can even kill notepad process. However, for some reason, showWindow works randomly. Most of the time it spawns something like GDI+server titled empty windows and etc and rarely pops the notepad.
What am I doing wrong?
ShowWindow expects a window handle, not a process handle.
Try passing the MainWindowHandle instead.
SetForegroundWindow(p.MainWindowHandle);
ShowWindow(p.MainWindowHandle, ShowWindowEnum.Show);
This should be ok for Notepad.exe, but won't be generally reliable for applications that have multiple top level windows.
Related
I have an application that I would like to close from my current C# application. The problem is that the application I want to close has an exit confirmation that requires the user to confirm the closing of the application.
When I use this code:
foreach (Process process in runningProcesses)
{
if (process.ProcessName == "ProcessName")
process.CloseMainWindow();
}
the exit confirmation popup still appears on the other application.
When questions similar to this are asked elsewhere, all I can find are people suggesting process.Kill() to get past the exit confirmation. This is not an option for me as I need the other application to close down gently.
Is there a way to send a closing message to the other application that will force it to start its shutdown process without killing the process abruptly?
If you have to close the application gently and it displays a confirmation when trying to close it, then you'll have to handle it as well.
The actual way to do that depends on what exactly the popup is. If it's a standard dialog, something like the following could suffice:
SendMessage(hDlg, WM_COMMAND, IDOK, 0);
If it's a less standard dialog, but still using standard Windows components (like MFC or WinForms or something), you'll have to inspect its window structure (using Spy++ for example), get the handle of the button you need to press and use something like:
SendMessage(hBtn, BM_CLICK, 0, 0);
If however the dialog doesn't use standard windows (like Qt or WPF), you'll need a lot more specialized code. I'd suggest hooking into the parent dialog and pressing the button yourself to see what events are triggered (Spy++ can do that) and mimicking them with SendMessage.
You can send a WM_ENDSESSION message, which in most applications cause all forms to gracefully close.
PostMessage(process.MainWindowHandle, WM_ENDSESSION, IntPtr.Zero, new IntPtr(ENDSESSION_CLOSEAPP));
Definitions:
[DllImport("user32.dll")]
public static extern IntPtr PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
const int WM_ENDSESSION = 0x16;
const int ENDSESSION_CLOSEAPP = 0x1;
I'm starting internet explorer process. the problem is that it always return zero in p.MainWindowHandle.
my objective is to get mainwindowHandler and minimize that particular window which is just started. the same code is working with chrome browser. but in internet explorer it's not working.
my code is below.
Process p = Process.Start("IEXPLORE.EXE", "www.google.com");
ShowWindow(p.MainWindowHandle, 2);
ShowWindow is a method resize window.
Among the many other reasons (see comments to the question), you have to wait for process to create the main window:
// Process is IDisposable, wrap it into using
using (Process p = Process.Start("IEXPLORE.EXE", "www.google.com")) {
...
// wait till the process creates the main window
p.WaitForInputIdle();
// Main window (if any) has been created, so we can ask for its handle
ShowWindow(p.MainWindowHandle, 2);
}
I am creating a scheduled task to run process monitor at its highest privileges. I have a windows service that executes the scheduled task on start. Thus on start of my service, process monitor.exe will be executed shown in a window. But I don't want to see the window. I just want the process monitor.exe to run in the background without displaying any windows.
In AutoIT, there is a command: Run (Procmon.exe,"",#SW_Hide) #SW_Hide = Hidden Window
I tried this:
foreach (Process pr in Process.GetProcesses())
{
if(pr.ProcessName == "procmon")
{
hWnd = pr.MainWindowHandle.ToInt32();
ShowWindow(hWnd, SW_HIDE);
}
}
It's better to tell the process to show no window in the first place, instead of hiding it afterwards.
When running a program from .net you usually already have a ProcessStartInfo. Then just set its WindowStyle property to ProcessWindowStyle.Hidden and that should take care of it.
I haven't tried this myself, but that's the way you usually do it when calling the WinApi functions directly.
http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.windowstyle.aspx
http://msdn.microsoft.com/en-us/library/system.diagnostics.processwindowstyle.aspx
You need to get Window Handle of Process Monitor first and then you need to call ShowWindow with SW_HIDE to hide it.
You can use FindWindow to get the Window Handle of the ProcMon window.
Edit:
After looking at your code, I tried at my end and it works with the following code:
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
public static void HideWindow()
{
int SW_HIDE = 0;
foreach (Process pr in Process.GetProcesses())
{
if (pr.ProcessName.Contains("Procmon"))
{
//Int32 hWnd = pr.MainWindowHandle.ToInt32();
ShowWindow(pr.MainWindowHandle, SW_HIDE);
}
}
}
static void Main(string[] args)
{
HideWindow();
}
Most likely, the problem with your code is that you are trying to find an exact match of the process name which isn't there.
Procmon has built-in functionality to automatically log at startup, if that's what you're trying to accomplish.
I have a situation where I'm starting a process in my code in order to set up an IPC channel. The process I'm starting is an MFC application with no CLR support. The application from which I am starting this process is a C# module in a WPF application (thought I don't think that that is consequential to my problem). This works with a version of the application that does support CLR, and it works on every computer except the deployment target, a touch screen computer with Windows 7. But for some reason, when I try it with this exact scenario, the Process object never resolves a main window handle (Process.MainWindowHandle). Is there another (perhaps even pinvoke) method of doing this? Is this a security thing? I'm the one staring the process. The process's main window handle does exist. I don't see what could be wrong.
If it helps, here is my code.
_applicationProcess = new Process();
_applicationProcess.StartInfo.FileName = _strProcessPath;
_applicationProcess.StartInfo.Arguments = _strProcessArguments;
_applicationProcess.Start();
long nTicks = Environment.TickCount;
if (_applicationProcess.WaitForInputIdle(1 /*minute(s)*/ * 60000))
{
try
{
do
{
// Don't let total processing take more than 1 minute(s).
if (Environment.TickCount > nTicks + 1 /*minute(s)*/ * 60000)
throw new ApplicationException("MFCApplication.Startup failed! The main window handle is zero!");
_applicationProcess.Refresh();
}
while (_applicationProcess.MainWindowHandle.ToInt32() == 0);
_applicationHandle = new IntPtr(_applicationProcess.MainWindowHandle.ToInt32());
}
catch (Exception ex)
{
//Do some stuff...
throw;
}
}
else
{
// Do exception handling.
}
The ApplicationException is hit after a minute of trying to get a main window handle other than zero.
The value you get out of Process.MainWindowHandle is unfortunately a guess. There is no API function available to a program that lets it tell Windows "this is my main window". The rule it uses is documented, it is the first window that's created by a process when it gets started. That causes trouble if that first window is, say, a login window or a splash screen.
Not much you can do about this, you have to know more about how the program behaves to find that real main window. Enumerating windows with EnumThreadWindows() could help you find it, as long as the first window was created on the same thread as the main window. A more elaborate EnumWindows() will be necessary if that is not the case.
My habit is to call EnumWindows in a loop combined with GetWindowThreadProcessId to find the window handle.
C Code, adapt to your language
DWORD TargetHWND;
//...
while (EnumWindows(EnumWndProc, (LPARAM)(DWORD)pid)) {
Sleep(100);
}
//...
BOOL EnumWndProc(HWND hWnd, LPARAM lParam) {
DWORD pid = (DWORD)-1;
GetWindowThreadProcessId(hWnd, &pid);
if (pid == (DWORD)lParam) {
TargetHWND = hWnd;
return FALSE;
}
return TRUE;
}
In order to get MainWindowHandle by means of your process, please make sure your WPF application is shown on the taskbar i.e ShowInTaskbar="True" and set Application.Current.MainWindow property to the window that you'd like to set as your main window.
If I execute code below in my WPF main window without setting ShowInTaskbar="True" I always got 0 as the MainWindowHandle because my WPF window was full screen and not displayed on the taskbar.
Application.Current.MainWindow = this;
var Query = System.Diagnostics.Process.GetProcessesByName("ProcessName");
if (Query.Any())
{
Query.FirstOrDefault().Refresh();
MessageBox.Show(Query.FirstOrDefault().MainWindowHandle.ToInt32().ToString());
}
I don't know why it could be different, but after you create the process, try doing:
Process[] allProcesses = Process.GetProcessesByName("YourWindowTitle");
and see if any of the processes returned have a MainWindowHandle.
Good day everyone.
This problem was part of another one which it as been solved, i realized that what i thought it was the problem after all, it wasn't. Still thanks to that I've learned a couple things.
My application does loads of work with IE and from time to time, IE is redirected to a website with some bad Javascript code that ends up blocking IE interface. And consequently blocking my application too once everything on my application is running on the same Thread.
To counteract that problem, at startup my application runs a static method in another Thread that every 15 seconds does a simple check if IE is responding or not, and if IE isn't responding, he closes all its process's, liberating the lock on my application main Thread and then my application can resume its work.
To find if IE process's are responding i had a simple code like this:
bool terminate = false;
foreach (System.Diagnostics.Process exe in System.Diagnostics.Process.GetProcesses())
{
if (exe.ProcessName.StartsWith("iexplore"))
{
if (exe.Responding == false)
{
terminate = true;
break;
}
}
}
// Code to close all IE process's...
In order to the Process.Responding property finds if the process is responding, and according to information on MSDN, this property needs another property named MainWindowHandle to be available in order to complete the process of checking. And if MainWindowHandle isn't available Process.Responding always returns true even if the process isn't responding.
And for some reason which i don't know. In Windows XP MainWindowHandle isn't available there so Responding isn't accurate.
Thats why i need to know another way to find if a specific process is responding or not in Windows XP.
Any help is appreciated, thanks.
PS: If your looking for a website to freeze IE here goes: http://aboutmycollege.com/
EDIT: Following 0xA3 suggestion:
I went through all IE process's checking if they had the MainWindowHandle property, those who had that property i send they Responding property to a MessageBox and they report correctly when IE isn't responding on Windows 7 but not on XP.
I executed this code every 15 seconds:
foreach (System.Diagnostics.Process exe in System.Diagnostics.Process.GetProcesses())
{
if (exe.ProcessName.StartsWith("iexplore"))
{
if (exe.MainWindowHandle == IntPtr.Zero)
{
System.Windows.Forms.MessageBox.Show("Process doesn't have MainWindowHandle");
}
else
{
System.Windows.Forms.MessageBox.Show("Process Responding: " + exe.Responding.ToString());
}
}
}
In Windows 7 and Xp he reports the Process's of IE that don't have the MainWindowHandle property, and in Windows 7 he also reports correctly when IE isn't responding. But in XP all IE process's with MainWindowHandle are always responding even when they aren't.
IE is special because each tab has its own process plus there is an additional parent IE process. In fact, only the parent process will have a valid MainWindowHandle.
Did you check whether MainWindowHandle is null for all these processes? If it isn't I think your code should work as expected on XP as well.
Update
Since checking all IE instances didn't help, the next thing I would try is to modify the timeout that is used by Process.Responding. The property internally calls the SendMessageTimeout api function and then checks the return value whether a timeout occurred. If so, the process is assumed to be hanging. The timeout is a hard-coded value of 5 seconds.
You can call SendMessageTimeout yourself using P/Invoke and vary the timeout. Possibly a shorter value would give better results on Windows XP:
[DllImport("user32.dll", CharSet=CharSet.Auto)]
static extern IntPtr SendMessageTimeout(
HandleRef hWnd,
int msg,
IntPtr wParam,
IntPtr lParam,
int flags,
int timeout,
out IntPtr pdwResult);
const int SMTO_ABORTIFHUNG = 2;
bool IsResponding(Process process)
{
HandeRef handleRef = new HandleRef(process, process.MainWindowHandle);
int timeout = 2000;
IntPtr lpdwResult;
IntPtr lResult = SendMessageTimeout(
handleRef,
0,
IntPtr.Zero,
IntPtr.Zero,
SMTO_ABORTIFHUNG,
timeout,
out lpdwResult);
return lResult != IntPtr.Zero;
}