New to C#. But due to circumstances at work I have to "learn on the fly."
Been struggling the last 2 days with my code and I consumed as many questions here and articles on MSDN as I could but I think they confused me further.
I launch app A using my code. App A launches app B (I cannot launch app B, I'm beyond that).
What I want to do w/ my code is the moment app B's MainWindowTitle is available, hide the window.
So far, I can only accomplish this w/ a Thread.Sleep(xxx); before the code you see below.
I want to avoid using timers.
What I'm trying to do is loop the code below until it is true.
When app A launches app B, it takes a few seconds for the MainWindowTitle to become available. But the code runs so fast that it's not available yet and the code is done.
IntPtr hWnd = IntPtr.Zero;
foreach (Process procList in Process.GetProcess())
{
if (procList.MainWindowTitle.Contains("SAP Logon"))
{
hWnd = procList.MainWindowHandle;
}
}
ShowWindow(hWnd, 0);
That code only works if I precede it with something like:
Thread.Sleep(10000);
before the entire block of code. And the only reason it works is b/c it allows enough time to pass for the Window to open and contain the title I'm looking for.
I have tried while loops.
Outside the 'foreach'
Outside the 'if'
Around the 'foreach' (that locked up the system really quickly...) hah!
Around the 'if'
I feel like one of the following should work, but it doesn't, or I'm completely screwing it up.
while (!procList.MainWindowTitle.Contains("SAP Logon")) { } // ! at the beginning OR
while (procList.MainWindowTitle.Contains("SAP Logon") == null) { } // equaling null OR
while (procList.MainWindowTitle.Contains("SAP Logon") < 0) { } // etc., etc.,
while (procList.MainWindowTitle.DOESNOTContain("SAP Logon")) { } // I know this is wrong but it almost seems like what I need...
Anyone have any suggestions? My brain is scrambled eggs and this is the last bit that I need to finish this app.
If my only alternative IS Thread.Sleep(), so be it, but I would prefer to not use it.
One last thing: I have to target .net 2.0.
Thank you kindly!
Your idea of using the while loop should work. You could try something like this:
IntPtr hWnd = IntPtr.Zero;
bool isFound = false;
while(!isFound)
{
foreach (Process procList in Process.GetProcess())
{
if (procList.MainWindowTitle.Contains("SAP Logon"))
{
isFound = true;
hWnd = procList.MainWindowHandle;
}
}
Thread.Sleep(100); // You may or may not want this
}
ShowWindow(hWnd, 0);
Instead of checking for the caption of the app in every single process, you can check using just the name of the EXE itself. I would also put in a timeout for good measure. For example, with Notepad you'd do:
Process[] ps;
DateTime timeout = DateTime.Now.AddSeconds(30);
do
{
System.Threading.Thread.Sleep(100);
ps = Process.GetProcessesByName("notepad"); // <--- no path, AND no extension (just the EXE name)
} while (ps.Length == 0 && timeout > DateTime.Now);
if (ps.Length > 0)
{
ShowWindow(ps[0].MainWindowHandle, 0);
}
else
{
MessageBox.Show("Process Not Found within Timeout Period", "Process Failed to Spawn");
}
Have you tried or seen this:
.NET Events for Process executable start
This should do what you are looking for...
Related
I want to constantly check if a background process is running or not, I only have one label (to display the result)
My code that shows whether it's running or not is:
Process[] plist = Process.GetProcessesByName("chrome");
if (plist.Length > 0)
{
label1.ForeColor = Color.Green;
label1.Text = "FOUND";
}
else
{
label1.ForeColor = Color.Red;
label1.Text = "NOT FOUND";
}
And when run it, it works, but when I close the process it still shows "FOUND", how can I make it always check if plist.Lenght is 0 or >0?
p.s: I tried some duplicate questions etc and I didn't get it to work.
using System;
using System.Diagnostics;
namespace Program
{
class Program
{
static void Main(string[] args)
{
Process[] plist = Process.GetProcessesByName("msedge");
if (plist.Length > 0)
{
Console.WriteLine(plist[0].ProcessName);
}
else
{
Console.WriteLine("NotFound");
}
}
}
}
The code above seems to be working just fine. Two things I would check are:
open up task manager
ensure all chrome processes are closed, even if your chrome web browser is closed, there might be some open here. I used msedge, and it seemed to work just fine.
You may have hard looped your UI thread. This means it is so busy checking processes, that it has no time to update your label. normally you do not do tasks like this on the UI thread, but instead break them off on side threads. Alternatively you can use a timer on the main thread, check every couple of miliseconds. The last but Bad way to do this is to call:
label1.Invalidate();
Application.DoEvents();
These lines will force the UI to update and pause your process check, but is really only good for testing / development. As this will cause all of your processes to lag, not a good thing for production enviroments.
I am trying to automate Windows 10 installation by first mounting the .iso file on the drive. And then using c# to start windows 10 installation by using this below code which passes the keys to the installation application
[DllImport("user32.dll")]
static extern int SetForegroundWindow(IntPtr point);
public static void Main(String[] args){
Process p1 = Process.Start("h:\\setup.exe");
IntPtr h = p1.MainWindowHandle;
SetForegroundWindow(h);
Thread.Sleep(30000);
SendKeys.SendWait("{ENTER}");
Thread.Sleep(1000);
SendKeys.SendWait("{ENTER}");
Thread.Sleep(1000);
SendKeys.SendWait("{ENTER}");
}
But the problem is that the setup window is not taking the signal of the ENTER key in the code. The setup window is starting with this code. After that, nothing is happening.
Process p1 = Process.Start("h:\\setup.exe");
I tried using notepad instead of setup.exe in the code which is taking all the ENTER keys. Please tell me if anyone has a solution. Thank you
Disclaimer:
I would advise against automating a Windows setup using something like
SendKeys as you can't guarantee a consistent behavior and could
easily mess things up. You may consider looking for different
approaches as suggested by lan Kemp in the comments. This answer
only shows you how to get the handle of the setup window correctly.
You may use it at your own risk.
Update:
Apparently, the Windows 10 setup executable ("Setup.exe") starts another process called "SetupPrep.exe" which starts a third process called "SetupHost.exe" (the one you're after). So, what you can do is start the main process, wait for the target process to start and obtain a MainWindowHandle before executing the remaining code:
Process p1 = Process.Start("H:\\setup.exe");
Process targetProcess;
do
{
Thread.Sleep(500);
targetProcess = Process.GetProcessesByName("SetupHost").FirstOrDefault();
} while (targetProcess == null || targetProcess.MainWindowHandle == IntPtr.Zero);
IntPtr h = targetProcess.MainWindowHandle;
// ...
This should solve your problem, however, it's not a wise idea to use SendKeys for this purpose. Please refer to the disclaimer above.
Original answer:
Did you make sure that h does actually have a value (other than IntPtr.Zero)? Because it probably doesn't have the actual window handle since you don't give the process enough time to start and obtain a window handle.
Try something like this:
Process p1 = Process.Start("h:\\setup.exe");
while (p1.MainWindowHandle == IntPtr.Zero)
{
Thread.Sleep(500);
}
IntPtr h = p1.MainWindowHandle;
// ...
I'm writing a simple C# console application which opens up four instances of Windows Explorer and uses Pinvoke's MoveWindow to place them around the screen. My problem is that the Process.Start command seems to run too slowly, and the MoveWindow function cannot find the process unless I deliberately slow the program down. Here is my code:
Process.Start(new ProcessStartInfo()
{
FileName = "explorer",
Arguments = location, //Defined elsewhere (for testing just ".")
UseShellExecute = false
});
int[] pos = GetPositions(position); //Little function which gets the positions I want for this window
System.Threading.Thread.Sleep(500);
IntPtr hnd = GetForegroundWindow();
bool ok = MoveWindow(hnd, pos[0], pos[1], pos[2], pos[3], false);
See how I'm having to Sleep for an (arbitrary) half second. It's not ideal, because I don't know the specifications of the machine it will be running on. It could end up being either inefficient on a fast machine or could break on a slower machine. Is there a more concrete way of waiting until a process has started where I don't have to arbitrarily wait for a set time?
Also, on a semi-related note, you may notice a bit of cowboy code which just gets the foreground window to grab the window I want moved. This is because I had an absolute mare trying to pick out specific Window Explorer processes. From what I can tell they just don't work the same way as anything else (like when I was testing with notepad or IE) and just passing a handle doesn't work. Anyone who's familiar with this problem, feel free to contribute, but if not don't spend any time on it - clunky as this solution is, it works, and for a little application I don't want to spend hours bashing my head against the keyboard trying to figure out the proper way of doing it.
In theory, you would be able to call Process.WaitForInputIdle() which waits for a message loop to be created and be up and running in the newly started process. However, this does not work with all applications (and most likely not with Windows Explorer).
A cheap trick is to poll for the main window of the process to be created (source):
public static bool WaitForMainWindow(this Process process)
{
while (!process.HasExited && process.MainWindowHandle == IntPtr.Zero)
{
Thread.Sleep(10);
}
return !process.HasExited;
}
You might want to make this more robust by adding a timeout:
public static bool WaitForMainWindow(this Process process, uint timeout)
{
var start = DateTime.Now;
while (!process.HasExited && process.MainWindowHandle == IntPtr.Zero)
{
Thread.Sleep(10);
if ((DateTime.Now - start).TotalMilliseconds >= timeout)
{
return false;
}
}
return !process.HasExited;
}
You can try something like this
while(!process.HasExited)
{
//process running
}
//Done
I start the Windows On-Screen-Keyboard like that:
s_onScreenKeyboard = new Process();
s_onScreenKeyboard.StartInfo = new ProcessStartInfo("osk.exe");
s_onScreenKeyboard.EnableRaisingEvents = true;
s_onScreenKeyboard.Exited += new EventHandler(s_onScreenKeyboard_Exited);
s_onScreenKeyboard.Start();
This works fine, but when I try to stop it using the following code, it does not work, i.e. the OSK keeps running and the method returns false:
s_onScreenKeyboard.CloseMainWindow();
if (!s_onScreenKeyboard.HasExited)
{
if (!s_onScreenKeyboard.WaitForExit(1000))
{
s_onScreenKeyboard.Close();
//s_onScreenKeyboard.Kill();
}
}
When uncommenting s_onScreenKeyboard.Kill(); it is closed, but the problem is that osk.exe obviously uses another process called "msswchx.exe" which is not closed if I simply kill the OSK process. This way, I would end up with hundreds of these processes which is not what I want.
Another strange thing is that the CloseMainWindow() call worked at some time, but then it suddenly did not work anymore, and I do not remember what has changed.
Any ideas?
EDIT: I have found a solution myself. Please see my answer for details.
Background:
I am implementing an On-Screen-Keyboard for my application because it should work with a touchscreen. It is important that the keyboard layout matches the layout which is configured in Windows since the application will be shipped to many different countries. Therefore, instead of implementing a custom keyboard control with approx. 537 keyboard layouts (exaggerating a little here...), I wanted to utilize the Windows built-in On-Screen-Keyboard which adapts to the selected keyboard layout automatically, saving a lot of work for me.
I have found the/a solution myself:
When I successfully retrieve the MainWindowHandle after the process has been started, the call to CloseMainWindow() is also successful later on. I do not understand the reason for this, but the important thing is: it works!
BTW, for others having the same problem: The MainWindowHandle is not available immediately after starting the process. Obviously, it takes some milliseconds until the MainWindow is started which is why I use the following code to retrieve the handle:
DateTime start = DateTime.Now;
IntPtr handle = IntPtr.Zero;
while (handle == IntPtr.Zero && DateTime.Now - start <= TimeSpan.FromSeconds(2))
{
try
{
// sleep a while to allow the MainWindow to open...
System.Threading.Thread.Sleep(50);
handle = s_onScreenKeyboard.MainWindowHandle;
}
catch (Exception) { }
}
In this code I continuously get the MainWindowHandle every ~50ms as long as it is still equal to IntPtr.Zero. If the handle could not be retrieved after 2 seconds, I quit the loop to avoid an endless loop in case of error.
You need to wait untill the process finishes initialization, run
Process.WaitForInputIdle Method in order to do that.
I am making a program for handheld PDAs using .net 2.0 compact framework and I have this one part which I'm not proud of and I was hoping for a more elegant solution.
Basically the problem is another process using my file in this case its Windows Media Player. I start the process by passing the file location to Process.Start but it seems the process returned is short lived and it is spawning another process? So I tried looking up how to get child process information but had some problems with that (i think no processes were being returned for some reason).
So i currently do this dodgy fix
string processName = item.Text;
Process proc = Process.Start(processName, null);
if (!proc.Start())
MessageBox.Show("Failed to start process", "Error", MessageBoxButtons.OK, MessageBoxIcon.Hand, MessageBoxDefaultButton.Button1);
else
{
IntPtr newWindow = IntPtr.Zero;
TimeSpan limit = TimeSpan.FromSeconds(3);
DateTime start = DateTime.Now;
DateTime now = start;
// do while the following:
// window is not null
// window is not ourself
// under 3 seconds
do
{
newWindow = Win32.GetForegroundWindow();
now = DateTime.Now;
// taking too long
if (now - start > limit)
break;
}
while (newWindow == IntPtr.Zero || newWindow == this.Handle);
if (newWindow != IntPtr.Zero && newWindow != this.Handle)
{
uint processID = 0;
if (Win32.GetWindowThreadProcessId(newWindow, out processID) != 0)
{
//const int stringSize = 1024;
//StringBuilder sb = new StringBuilder(1024);
//Win32.GetWindowText(newWindow, sb, stringSize);
m_processes.Add(new ProcessIDWithName(processID, processName));
}
}
}
As you can see I don't like it and it's unreliable however it does work for now (i needed a solution whether it was bad or not).
Why do I need the process ID? Because windows media player is keeping the file open on me and I cannot move/delete the file and therefore I need to kill the process off before I do so. I could do a similar fix with FindWindow but I was thinking more generically as it might not be a media file opened in windows media player.
So basically I would like a better solution if possible!
Also if you wondering why I'm not using a Stopwatch its because it doesn't seem to exist in .net 2.0 cf, also I don't need accuracy to that extent.
There are loads of questions that pop up here.
Why aren't you executing media player itself instead of shellexecuting the name of the target file?
How do you know when the media is done playing in order to close the file?
Why not use the toolhelp APIs to simply enumerate processes instead of the wacky GetForegroundWindow/GetWindowsThreadProcessId shenanigans?
Why aren't you just using the Media Player ActiveX control instead of this kludge so you'd actually have control over things?
If you intend to make this generic for any file (i.e. not just media, but maybe something like the Word viewer, etc) then you're really out of luck and need to rethink whatever it is you're trying to do (you've not told us what you're trying to achieve, only how you['ve decided to implement it). Applications don't normally close in WinMo, they typically just lose focus of get minimized, so you don't really know when a user is "done" with the file.
The application associated with the file may already be running, so terminating it yourself is an unfriendly thing to do.
The target application really is not designed to give you a callback when it's done with any particular file.
I have no experience with PDA programming, bu you can try to use Job objects (see http://msdn.microsoft.com/en-us/library/ms684847.aspx#job_object_functions). With respect of CreateJobObject you can create a new job. Then you create a suspended process and use AssignProcessToJobObject to assign the new process to th job object. Then you can resume the process.
The advantage of job object is, that you can receive full control of all child processes of the job. You can use TerminateJobObject to terminate all processes. If you create creates an I/O completion port to wait for the end of the direct started process and all it's child processes or monitor of all child processes created and much more. If you need I could post some code examples of links to code examples.