As stated in the comments above, a TabControl is perfectly suitable for your needs.
The Visual Studio WPF Designer allows you to visualize each TabItem
's content at design time:


By simply clicking on the TabItem's header, or focusing their respective XAML tags in the XAML editor:
<TabControl>
<TabItem Header="Tab Item #1"> <!-- Placing the keyboard cursor here will show Tab Item 1-->
<Border Background="Red"/>
</TabItem>
<TabItem Header="Tab Item #2"> <!-- Placing the keyboard cursor here will show Tab Item 2-->
<Border Background="Green"/>
</TabItem>
</TabControl>
If you don't want to show the tab headers, simply customize the TabControl's Template to only show the SelectedContent
, like this:
<TabControl>
<TabControl.Template>
<ControlTemplate TargetType="TabControl">
<ContentPresenter Content="{TemplateBinding SelectedContent}"/>
</ControlTemplate>
</TabControl.Template>
<!-- TabItems here -->
</TabControl>
This simple customization preserves the design time preview ability via the keyboard cursor in the XAML editor, while only showing the selected TabItem's content in the UI, with no headers whatsoever.
All this said, and as a side comment, you really need to leave behind the archaic winforms mentality.
First of all, there is no such thing as a "wrong control" in any context in WPF. The WPF Content Model allows for the composition of rich content in almost any situation for almost any parent container, enabling a much greater customizability than archaic technologies.
And no, a TabControl
(there is no such thing as a TabPage
in WPF) does NOT "only accept TabItems", because, just like any other ItemsControl, the TabControl
wraps each of it's items in an Item Container, provided that the item itself is not an item container.
This means that if you place for example, a <Checkbox/>
as an item of the TabControl
, WPF will automatically wrap the Checkbox
with a TabItem
. This behavior supports a great range of scenarios and allows for high levels of customizability and complex uses (such as DataBinding and Data Templating) without the need to introduce custom code. In contrast to some archaic technologies such as winforms which literally doesn't support anything except the default horrible stuff and have no support for DataBinding whatsoever.
If you have problems understanding WPF layout, See This Tutorial. Complex, resolution independent layouts are much more easily achieved in WPF (in comparison to useless winforms) due to WPF's pixel independent nature.