Controlling External .Net Processes

-
I have a project where I wanted to be able to provide my users with a button that would open an external application. The idea is that the interaction would be seamless so that from the users perspective, the external application would seem to be apart of my application. To pull this off, I needed to be able to bring the main window(s) of the external application to the front if I had already launched it but the user clicked the button again.

For this implementation, I tried to use the following .Net implementation:

_process.WaitForInputIdle(1000);
IntPtr mainWindowsHandle = _process.MainWindowHandle;
//show the process's window if applicable else inform the user
if (!mainWindowsHandle.Equals(IntPtr.Zero))
{
//show the process's main window
ShowWindow(mainWindowsHandle, 1);
SetForegroundWindow(mainWindowsHandle);
}

Here we get the handle to the main window of the process and we call the win32 ShowWindow and SetForegroundWindow methods to the front.

I went ahead and tried it out with Windows' Calculator and everything seemed to work perfectly. As it turns out, however, .Net applications tend to return IntPtr.Zero as their MainWindowHandle. This would cause this implementation to fail. So it was back to the drawing board.

I found an alternative implementation that would work for .Net applications as well by jumping through a few more win32 hoops. Here is the new improved implementation:

DateTime start = DateTime.Now;
IntPtr windowHandle = IntPtr.Zero;

int waitTime = 500;

EnumWindows(
(hWnd, lParam) =>
{
if (windowHandle == IntPtr.Zero && DateTime.Now.Subtract(start).TotalMilliseconds <>
{
uint pId = 0;
GetWindowThreadProcessId(hWnd, out pId);
if (pId == _process.Id)
{
windowHandle = hWnd;
}
}

return true;
},
IntPtr.Zero);


while (windowHandle == IntPtr.Zero && DateTime.Now.Subtract(start).TotalMilliseconds <>

//show the process's window if applicable else inform the user
if(windowHandle != IntPtr.Zero)
{
//show the process's main window
ShowWindow(windowHandle, SW_SHOWNORMAL);
SetForegroundWindow(windowHandle);
}

Here we use EnumWindows to give us a list handles to open windows and find the first window that has the process ID that we are interested in. This technique seems to prevent getting a bad handle to the main window.

Here are the pInvoke signature used in C# for this implementation:

[DllImport("user32.dll")]
static extern bool SetForegroundWindow(IntPtr hWnd);

const uint SW_SHOWNORMAL = 1;

[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hwnd, uint windowStyle);

private delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr lParam);

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool EnumWindows(EnumWindowsProc lpEnumFunc, IntPtr lParam);

[DllImport("user32.dll", SetLastError = true)]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

Comments

Post a Comment

Popular posts from this blog

Form.Show() From Another THread - C#.Net

-
Today I ran into a mojor headache. I have a main form that instantiates a secondary form from its constructor. I also register to a receive data event that I have based on a socket. Because the socket uses threading, when my event delegate is called, it is being called from the context of another thread. It is inside the execution of the delegate that I ran into trouble. When I receive data from the socket, I want to open the secondary form and do something with it. Immediately I know that I am going to have to use Invoke on the secondary form in order to safely modify it from the other thread. My original attempt looked like this (I will use an inline delegate here to simplify this listing): void dataReceived() { If(secondaryForm.InvokeRequired) { MethodInvoker myDelegate = delegate { secondaryForm.Show(); //do other work on secondaryForm }; secondaryForm.Invoke(myDelegate)
Read more

Hello World

-
This blog will be my attempt to keep track of random coding techniques that I run across, or anything else code related that I find useful. If all goes well, I will begin adding posts soon.
Read more

A Quick Note On Ports and Sockets

-
At this point, most people are familiar with the use of an IP address. Basically it is a unique number used on a network to identify a network computer. When we talk about computers communicating with each other, an IP address alone is useless. A single computer may have many programs running that want to communicate over the network. This means that a single address point (the IP address) is not enough to define what program a remote computer would like to communicate with. This is where port numbers come in. A program can bind itself to one or many open ports (meaning they are not currently in use by another program). Once bound to a port, a remote computer can communicate with a program by addressing the computer's address (IP) along with the program's address on that computer (Port). A common misconception is that a socket represents a bound port on a computer (the IP:Port pair). In reality, this is only half of what a socket represents. In fact, a socket represe
Read more