How can I get handle (IntPtr) to a "sub"-form in another application?
-
Ahhh, you mean this:
const uint WM_GETTEXT = 0x000D;
StringBuilder message = new StringBuilder(1000);
SendMessage(handle, WM_GETTEXT, message.Capacity, message);Yes, that works great!!! Thank you! This is the complete code:
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
WindowWrapper parentForm = ProcessWindowsHelper.getHandleToAnotherProcessWindow("TortoiseGitProc", "Switch/Checkout");
MessageBoxEx.Show(parentForm, "Hello on top of TortoiseGit Switch/Checkout dialog");
}
}
public class ProcessWindowsHelper
{
private delegate bool EnumThreadWndProc(IntPtr hWnd, IntPtr lp);
[DllImport("user32.dll")]
private static extern bool EnumThreadWindows(int tid, EnumThreadWndProc callback, IntPtr lp);
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, int wParam, StringBuilder lParam);
delegate bool EnumThreadDelegate(IntPtr hWnd, IntPtr lParam);private const uint WM\_GETTEXT = 0x000D; public static WindowWrapper getHandleToAnotherProcessWindow(string processName, string substringInAnotherProcessWindow) { Process myProcess = findProcessByName(processName); IEnumerable allHandlesInMyProcess = EnumerateProcessWindowHandles(myProcess.Id); foreach (IntPtr handle in allHandlesInMyProcess) { StringBuilder message = new StringBuilder(1000); SendMessage(handle, WM\_GETTEXT, message.Capacity, message); if (message.ToString().Contains(substringInAnotherProcessWindow)) { Debug.WriteLine(message); return new WindowWrapper(handle); } } return null; } private static IEnumerable EnumerateProcessWindowHandles(int processId) { List handles = new List(); ProcessThreadCollection processThreadCollection = Process.GetProcessById(processId).Threads; for (int i = 0; i < processThreadCollection.Count; i++) { ProcessThread thread; thread = processThreadCollection\[i\]; EnumThreadWindows(thread.Id, delegate(IntPtr hWnd, IntPtr lParam) { handles.Add(hWnd); return true; }, IntPtr.Zero); } return handles; } private static Process findWell, I guess no joy lasts forever... In case somebody is using bash.exe instead of TortoiseGit to Switch/Checkout, then I wanted to do the same thing with bash.exe as the parent form. But when I call
parentForm = ProcessWindowsHelper.getHandleToAnotherProcessWindow("bash", "MING")
then it seems the handles list inside the EnumerateProcessWindowHandles method doesn't get any elements.
private static IEnumerable EnumerateProcessWindowHandles(int processId) { List handles = new List(); ProcessThreadCollection processThreadCollection = Process.GetProcessById(processId).Threads; for (int i = 0; i < processThreadCollection.Count; i++) { ProcessThread thread; thread = processThreadCollection\[i\]; EnumThreadWindows(thread.Id, delegate(IntPtr hWnd, IntPtr lParam) { handles.Add(hWnd); return true; }, IntPtr.Zero); } return handles; }The call to Process.GetProcessById(processId).Threads returns 3 threads, but nothing gets added to the handles list. Does anybody know why? When I look at the information in Spy++ I see the following:
Window OOOA9B72 "MINGW64:/c/dummyRepo" mintty
Windows Properties, General tab:
Window Caption: MINGW64:/c/dummyRepo
Window Handle: OOOA9B72
Window Proc: (Unavailable)(Unicode)
Rectangle: (86, 89)-(681, 466), 595x377
Restored Rect: (86, 89)-(681, 466), 595x377
Client Rect: (8, 31)-(570, 369), 562x338
Instance Handle 00400000
Menu Handle 00000000
User Data 00000000
Windows Bytes: -
Well, I guess no joy lasts forever... In case somebody is using bash.exe instead of TortoiseGit to Switch/Checkout, then I wanted to do the same thing with bash.exe as the parent form. But when I call
parentForm = ProcessWindowsHelper.getHandleToAnotherProcessWindow("bash", "MING")
then it seems the handles list inside the EnumerateProcessWindowHandles method doesn't get any elements.
private static IEnumerable EnumerateProcessWindowHandles(int processId) { List handles = new List(); ProcessThreadCollection processThreadCollection = Process.GetProcessById(processId).Threads; for (int i = 0; i < processThreadCollection.Count; i++) { ProcessThread thread; thread = processThreadCollection\[i\]; EnumThreadWindows(thread.Id, delegate(IntPtr hWnd, IntPtr lParam) { handles.Add(hWnd); return true; }, IntPtr.Zero); } return handles; }The call to Process.GetProcessById(processId).Threads returns 3 threads, but nothing gets added to the handles list. Does anybody know why? When I look at the information in Spy++ I see the following:
Window OOOA9B72 "MINGW64:/c/dummyRepo" mintty
Windows Properties, General tab:
Window Caption: MINGW64:/c/dummyRepo
Window Handle: OOOA9B72
Window Proc: (Unavailable)(Unicode)
Rectangle: (86, 89)-(681, 466), 595x377
Restored Rect: (86, 89)-(681, 466), 595x377
Client Rect: (8, 31)-(570, 369), 562x338
Instance Handle 00400000
Menu Handle 00000000
User Data 00000000
Windows Bytes:Have you stepped through it in the debugger? Does it find the correct process? Which line of code is failing?
The difficult we do right away... ...the impossible takes slightly longer.
-
Have you stepped through it in the debugger? Does it find the correct process? Which line of code is failing?
The difficult we do right away... ...the impossible takes slightly longer.
Yes, I stepped it. I first rewrote the method EnumerateProcessWindowHandles according to this:
private static List handles;
private static IEnumerable EnumerateProcessWindowHandles(int processId)
{
handles = new List();
ProcessThreadCollection processThreadCollection = Process.GetProcessById(processId).Threads;
for (int i = 0; i < processThreadCollection.Count; i++)
{
ProcessThread thread; // If I put a breakpoint here, the debugger stops 3 times
thread = processThreadCollection[i];
EnumThreadWindows(thread.Id, myDelegate, IntPtr.Zero);
}
return handles;
}private static bool myDelegate(IntPtr hWnd, IntPtr lParam)
{
handles.Add(hWnd); // If I put a breakpoint here, then the debugger never stops
return true;
}So, something seems to go wrong inside the call to EnumThreadWindows, but that's a Win32 function and I don't know how to put a breakpoint inside it or how to step through it.
-
Yes, I stepped it. I first rewrote the method EnumerateProcessWindowHandles according to this:
private static List handles;
private static IEnumerable EnumerateProcessWindowHandles(int processId)
{
handles = new List();
ProcessThreadCollection processThreadCollection = Process.GetProcessById(processId).Threads;
for (int i = 0; i < processThreadCollection.Count; i++)
{
ProcessThread thread; // If I put a breakpoint here, the debugger stops 3 times
thread = processThreadCollection[i];
EnumThreadWindows(thread.Id, myDelegate, IntPtr.Zero);
}
return handles;
}private static bool myDelegate(IntPtr hWnd, IntPtr lParam)
{
handles.Add(hWnd); // If I put a breakpoint here, then the debugger never stops
return true;
}So, something seems to go wrong inside the call to EnumThreadWindows, but that's a Win32 function and I don't know how to put a breakpoint inside it or how to step through it.
You need to put a breakpoint inside the "myDelegate" callback to see if ANY windows are being found, not just ones that match your substring. But first, verify that it is indeed finding the correct process. Compare the ProcessId to the one shown by Task Manager. EDIT: I'm sorry I didn't see that you had already tried the breakpoint inside the callback. The only thing I can think of at this moment is to make sure it is finding the correct process.
The difficult we do right away... ...the impossible takes slightly longer.
-
You need to put a breakpoint inside the "myDelegate" callback to see if ANY windows are being found, not just ones that match your substring. But first, verify that it is indeed finding the correct process. Compare the ProcessId to the one shown by Task Manager. EDIT: I'm sorry I didn't see that you had already tried the breakpoint inside the callback. The only thing I can think of at this moment is to make sure it is finding the correct process.
The difficult we do right away... ...the impossible takes slightly longer.
-
It is finding the right bash.exe process (there is only 1 running) and it successfully finds its 3 threads. As you said, the filtering with the substrings happens later and by then there are no handles at all to filter.
I have one last thing. I'm not familiar with bash, is it a command line program?
The difficult we do right away... ...the impossible takes slightly longer.
-
I have one last thing. I'm not familiar with bash, is it a command line program?
The difficult we do right away... ...the impossible takes slightly longer.
Yes, I think it's some kind of command prompt that is standard for Unix systems, but it exists for Windows also. I've seen some of my colleagues (those that prefer typing over interacting with GUI:s) type
$ git.exe checkout develop
when they want to checkout in Git.
-
Yes, I think it's some kind of command prompt that is standard for Unix systems, but it exists for Windows also. I've seen some of my colleagues (those that prefer typing over interacting with GUI:s) type
$ git.exe checkout develop
when they want to checkout in Git.
Bingo! That must be why you're not finding any Windows. I can think of two possibilities at this point. 1. It might be that you need to find bash's parent process and enumerate the windows of that process instead. 2. It might be that the Linux Subsystem is interfering somehow.
The difficult we do right away... ...the impossible takes slightly longer.
-
Bingo! That must be why you're not finding any Windows. I can think of two possibilities at this point. 1. It might be that you need to find bash's parent process and enumerate the windows of that process instead. 2. It might be that the Linux Subsystem is interfering somehow.
The difficult we do right away... ...the impossible takes slightly longer.
When I closed my bash.exe command prompt, I could see that the following processes disappeared: backgroundTaskHost, bash, conhost, git-bash, mintty and RuntimeBroker. When I tried mintty instead of bash, then it worked great! Again, thanks for your help!
-
When I closed my bash.exe command prompt, I could see that the following processes disappeared: backgroundTaskHost, bash, conhost, git-bash, mintty and RuntimeBroker. When I tried mintty instead of bash, then it worked great! Again, thanks for your help!
Happy to help! :)
The difficult we do right away... ...the impossible takes slightly longer.
