Reputation: 180934
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:
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?
Upvotes: 6
Views: 2733
Reputation: 141
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!
Upvotes: 1
Reputation: 84734
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.
Upvotes: 3
Reputation: 61
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);
}
Upvotes: 1
Reputation: 158309
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.
Upvotes: 7