As far as I know, using SetParent with handles from different processes is an undocumented feature and not allowed by Microsft.

Hi Alon,

Since you didn't say when the form created by the child process is on top of the "parent" form, should or should not the parent form being able to have input focus, here I assume what you want is something works like a modal dialog. The following code starts a Notepad process, and makes sure the Notepad window is always in front of the MainForm. The basic idea is to intercept the activate messages of the MainForm, insert the MainForm after the Notepad window in the Z order and set the Notepad window foreground.

public partial class MainForm : Form
{
    [DllImport("user32.dll")]
    private static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, uint uFlags);

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

    [DllImport("user32.dll")]
    private static extern bool ReleaseCapture();

    private const uint SWP_NOSIZE = 0x0001;
    private const uint SWP_NOMOVE = 0x0002;

    private const int WM_ACTIVATE = 0x0006;
    private const int WM_MOUSEACTIVATE = 0x0021;
    private const int MA_NOACTIVATEANDEAT = 4;

    public MainForm()
    {
        InitializeComponent();
    }

    Process notepad = null;

    private void MainForm_Load(object sender, EventArgs e)
    {
        notepad = Process.Start("notepad.exe");
        notepad.WaitForInputIdle();
    }

    protected override void WndProc(ref Message m)
    {
        switch (m.Msg)
        {
            case WM_MOUSEACTIVATE:
                SetBehind();
                m.Result = new IntPtr(MA_NOACTIVATEANDEAT);
                return;

            case WM_ACTIVATE:
                SetBehind();
                m.Result = IntPtr.Zero;
                return;
        }

        base.WndProc(ref m);
    }

    private void SetBehind()
    {
        if (notepad != null &&
            !notepad.HasExited)
        {
            ReleaseCapture();
            SetWindowPos(this.Handle,
                notepad.MainWindowHandle,
                0, 0, 0, 0,
                SWP_NOSIZE | SWP_NOMOVE);
            SetForegroundWindow(notepad.MainWindowHandle);
        }
    }
}

Please let me know if this is what you want.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg[at]microsoft.com

What you are trying to do is strictly forbidden by the Windows SDK docs, the parent window must belong to the same process.  There are however app compat hacks in Windows that might make it work for you.  They were designed to support Windows 3.x programs where this wasn't a problem because 3.x didn't support multitasking.  Specifically Office programs are known to not support this.  You'll have to try.

---

Hans Passant.

Hi Jie,

Thanks for your reply. I like your solution but I think something is still missing in my case-

I know that there are more messages for activating the window (other than the two you've mentioned in your code).

Do you know where can I find more information on these missing messages?

Thanks in advance,

Alon.

Hi Alon,

Yes, I'm aware of that. If we were working on a native C/C++ project, then we can use hooks to monitor the child process and make sure the two windows stick together. However, we can't do that in .NET because we don't want to inject CLR into other processes.

I can't think of a better solution right now. Althought the word "Timer" is hopping up and down somewhere in my mind, I don't want to do that ugly workaround - periodically check the Z order and fix it if some other window is inserted between our windows.

Or if you have control over the child application, maybe making some changes to the child app code so it will be aware of the parent app can also solve the problem.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg[at]microsoft.com