Implementing multiple screens in an Application

Weird question, but one that puzzles me a bit. In the old days when we had Terminals and DOS, applications generally only had one "window", and that was a fullscreen one. When people switched functions, there was no concept of opening a new window, but instead the content of the main window was overwritten. So there was only one ma开发者_运维问答in window, but multiple screens that were rendered in it.

How would one create something like that in a modern application, either WinForms or WPF?

There seem to be two approaches:

• Have multiple Windows. This is the usual approach and usually this makes sense to allow the user to work with multiple windows at the same time, but this may not be required/desired. Using ShowDialog() instead of Show() is the usual way to make the second Window Modal.
• Have only one Window, but with a TabControl on it. Hide the tabs and switch them programatically. This is close to the "One Window, multiple screens" behavior, but naturally it gets messy as you have all controls in the same Form class (although one could argue that this forces proper naming of the controls. Also, one could recommend to use partial classes and one .cs per screen)

I wonder if there is a better way? Essentially something that says "Look, I don't care about stuff like border style/icons or the main menu strip. All I want is that you render this screen into this area". Kinda like ASP.net Master Pages where the actual pages only define content that gets rendered into Placeholders.

Is there some proper mechanism to do something like that?

Or is there something wrong with the whole approach?

One approach would be to implement each screen as a user control and dynamically load and unload these controls in the main window as needed. I have used that approach in a windows mobile application and it has worked out quite well.

Considering you mentioned WPF, it's worth mentioning that Prism (the composite UI framework from MPP) would implement that using multiple Views (UserControls) either within a single Controller (for the same general aggregate) or multiple Controllers (across several aggregates).

Either the view or its presenter can trigger a command (or broadcast an event via IEventAggregator) and your navigation controller can respond by changing the current view assigned to the appropriate "region" (you might only have one). In fact, Prism's region model is quite similar to the MasterPage/Placeholder model, so you might want to look into that.

Prism might also include navigation history (back/forward) tracking, but I've not used it if it does.

I have not heard of a specific framework to accomplish that, but I would make each page a UserControl, or possibly a subclass of a control with the desired rendering logic. These page controls would all be members of the form, and added to its Controls collection as needed (or if there are too many of them, created as needed). They would have properties like Dock = DockStyle.Fill set in initialization. When changing pages:

void ChangePage(object sender, EventArgs e)
{
   Controls.Clear();
   Controls.Add(sender as Control);
}

I work as a C# developer and i can tell you that step by step I start using UserControl for multiple screens (pages) applications. I build my base class for a page, named BasePage that extends UserControl and I extend it for every page that I need (MainPage, SettingsPage etc). In the MainForm (the only form of the app) i have added a BasePage Control (ex. named CurrentPage) where I can load the needed page. from the MainForm I send needed events to the CurrentPage. I think this is the best solution for this kind of application where you need multiple forms in one form. This is the structure that I use for all my multiple pages applications.

If you use tab control you will end up choking your form with all the controls from all tabs loaded at the same time. I saw projects with 10+ tabs, very complex applications that are very slow and hard to code on.

I Hope you'll find this answer useful!