[DllImport("user32.dll")]
static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);
Declare Auto Function SetParent Lib "user32" (ByVal hWndChild As IntPtr, _
ByVal hWndNewParent As IntPtr) As IntPtr
None.
None.
Use this to create forms and then place child windows on it.
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()
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.