This would be a misuse of
library and intended UI structure. A panel is designed to be hosted by a Form, nor a Form is designed to be hosted by any Control (including other Form).
Even though it is technically possible to achieve using P/Invoked raw Windows API
SetParent, it won't work through pure .NET code, as the properties
System.Windows.Control.Controls are specifically designed to throw an exception on an attempt to make a form a child of any control.
are specifically designed to throw an exception
"Top-level control cannot be added to a control" on an attempt to make a form a child of any control. This can be worked around by setting
, as Bill pointed out (see his comment below). If you try to do that, you will see that the non-client area of the child form is shown inside the parent control, so additional work around would be presenting a form without it:
Form child = ...
child.TopLevel = false;
child.ShowIcon = false;
child.FormBorderStyle = FormBorderStyle.None;
//or child.Parent = whateverPanel;
(The same effect can also be achieved using P/Invoked raw Windows API
SetParent, but I would not recommend it.
Using pure .NET API and avoiding P/Invoke is a very important factor in Forms programming. Using pure .NET keeps Forms application portable across many platforms (typically, under Mono, http://en.wikipedia.org/wiki/Mono_%28software%29[^], http://www.mono-project.com/[^]). A Form application can run on Linux, Mac and other systems without recompilation (I do it all the time), but a single P/Invoke will break such compatibility.
Anyway, there is simply no point in doing any of the above, see below.
Also, from the point of view or UI style, this would misuse a button, which should not be used for navigation purposes, because the button has no state reflecting "current position" in navigation.
The suggested behavior is simply never needed. The similar effect could be achieved if you replace FORM1, FORM2 and FORM3 with Panels. Instead of three buttons three list items or tree nodes could be used by a navigation-controlling
. A selected panel could be made visible and other panels hidden using the property
. However, using this navigation style when only three panels should be switched looks impractical (but could be very beneficial if the number items controlling switching panels would be so big that they might not fit the form). Instead,
should be used. It's ready-to-use, convenient and require very little coding.