views:

136

answers:

3

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 main 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?

+7  A: 

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.

Fredrik Mörk
+1; I was just writing a variation of this answer. Now I don't have to!
John Rudy
That's a great idea, especially because User Controls can be put in other containers 8like a panel), which makes the management painless.
Michael Stum
+1  A: 

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);
}
David Gannon
+3  A: 

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.

Richard Szalay