static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

Public Shared Function SetParent(ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As IntPtr

Declare Auto Function SetParent Lib "user32" (ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As IntPtr

    static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

    SetParent(proc.MainWindowHandle, this.panel1.Handle);

    /*SetParent(FindWindow(vbnullstring,"notepad.exe"),me.handle)

    SetParent(runProcess.MainWindowHandle, Me.Handle)

     public static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

         SetParent(p.MainWindowHandle, this.Handle);

     Declare Auto Function SetParent Lib "user32" (ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As IntPtr

     SetParent(p.MainWindowHandle, Me.Handle)

One thing that makes SetParent more useful than MDIParent is that there are cases in which a control may be unstable in a MDI interface.

An example of this that I have encountered is using the FarPoint Spread 3.0/6.0 ActiveX controls. These controls will throw a Runtime protected memory violation exception if they are hosted in a WinForms Form, instantiated and then the Form.MDIParent property is set to an MDI container Form but using the SetParent(childForm.Handle, Me.Handle) call works.