CODEWITHSUNDEEP
c#wpf
James Smithy Cleave
James Smithy Cleave

Reputation: 131

WPF FullScreen (MDI) but not MDI

I am redesigning my WinForms application using WPF, I was only 2 weeks in to the project and quickly learn't that many of the controls I needed would require custom controls while WPF allows me to design these easily.

So far I have a MainWindow.xaml, Login.xaml and Menu.xaml,

The idea is to display the login, upon verification show the menu then if that closes back to login inside the main window which would be full screen.

To get the functionality working I simply created the login and menu forms with the WindowStyle="none" and centered it to the screen, this obviously doesn't work because there is still a form but not linked to the main form.

In winforms I used MDI but reading this forum and looking at question MDI is frowned on, I looked at tab controls. So far I can find tutorials on using 1 form to display it but can not find a suitable tutorial for going login>menu>login

I don't want to be spoonfed, this project is just a practice project to try and get to grips with WPF but there are a lot of questions relating to the subject and everyone handles it differently it seams.

Thanks

Upvotes: 0

Views: 486

Answers (2)

Fede
Fede

Reputation: 44048

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.

Upvotes: 2

Spencer Ruport
Spencer Ruport

Reputation: 35117

Instead of thinking in terms of "forms" and "windows" think of how you might design this application as if it were a web application. The login "screen" can simply be a user control laid on top of everything else that prevents the user from interacting with any of the controls below while it is displayed.

Also don't reference controls within each other directly. Instead add events to each of your user controls and bind them to the appropriate methods in other controls in your MainWindow.

Upvotes: 0

Related Questions