C# Signature:

[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

VB .Net Signature:

<DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
Public Shared Function SetParent(ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As IntPtr
End Function

VB Signature:

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

User-Defined Types:

None.

Notes:

None.

Tips & Tricks:

Use this to create forms and then place child windows on it.

Sample Code:

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

    Me.SuspendLayout()
    Dim runProcess As New System.Diagnostics.Process
    Dim info As New System.Diagnostics.ProcessStartInfo
    info.FileName = "NotePad.exe"
    info.WindowStyle = ProcessWindowStyle.Normal
    runProcess = Process.Start(info)

    SetParent(runProcess.MainWindowHandle, Me.Handle)

    Me.ResumeLayout()

Alternative Managed API:

MDIParent and MDIChild do work for interforms.

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.