Without creating an overly complex answer, and without including concepts that are obviously new to you such as DelegateCommand(s) or WindowManager(s), this is a bare bones example of a Fullscreen application showing many different "sub windows" (which are not windows per se, but rather UserControls)
MainWindow:
<Window x:Class="FullScreenAppSample.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
WindowState="Maximized"
WindowStyle="None">
</Window>
Code Behind:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private void ShowLogin()
{
var loginview = new LoginView();
this.Content = loginview;
}
private void ShowMenu()
{
var menu = new MenuView();
this.Content = menu;
}
}
LoginView:
<UserControl x:Class="FullScreenAppSample.Login.LoginView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<!-- your login screen UI here -->
</UserControl>
MenuView:
<UserControl x:Class="FullScreenAppSample.Menu.MenuView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<!-- your Menu UI here -->
</UserControl>
This is what could be called a "View First" approach, where the View dictates the "flow" of the application by taking the responsibility of instantiating other views and making them visible.
That being said, I'll take a minute to address your assertion that
everyone handles it differently
Yes. The mainstream approach to creating WPF applications is something called MVVM, which was conceived as a WPF-specific version of Martin Fowler's Presentation Model. There are, however, many interpretations and many different versions of MVVM out there, together with many MVVM Frameworks, such as MVVM Light, Caliburn.Micro, and Microsoft's Prism (amongst many others).
Each of these frameworks provide the basic tooling (base classes, helper classes, services, abstractions, event aggregators and whatnot) to ease the development of large-scale, complex WPF applications.
Bottom line: there is not a definitive "right way" to handle things like View and ViewModel instantiantion / management in WPF, that will depend on your choice of MVVM Framework and the specifics of your project, such as need for testability.
I, personally, have taken various parts and components (and concepts, too) from several different frameworks and composed my own, ViewModel-first MVVM approach. I would recommend that you take some time to analyze your project requirements and consider whether using any of these.
