What is a proper way of building Winform apps with multiple "screens"

Question

What's a proper way of building a Winform app that has multiple 'screens'? For example, I'm trying to write a small backup program (mainly for giggles), and I've been dumping controls and containers onto the form.

I'm using panels and group boxes to separate out the different screens (eg: I'm using a panel to hold all of the controls for the "Settings" window, and another panel to show all the current backups that have been set up). Well, my form.cs file ballooned into a massive amount of code, and I feel like I'm doing something wrong. I can hardly find anything in the file, and I'm ready to start over. This project was just for me to expand my knowledge of C# and .NET, so starting a new project is not a huge deal.

Answer 1

There's a number of ways to control UI complexity.

• If you have lots of forms, you can choose a design pattern that manages transitions: Application Controller for example, or closer to the metal: State.
• You can compose groups of controls into single controls. In winforms, you use User Controls.
• If the complexity is coming from the quantity of code in your form, as opposed to the quantity of controls on the form, you could simply better encapsulate code into objects using standard object oriented programming techniques. Understanding the SOLID principles is a good place to start.
• Otherwise, there are patterns for working with user interfaces. Among other things (separation of concerns being prominent), they facilitate organization of code. Some common ones are MVC, MVP, MVVM

From your description, I'd use custom user controls to replace what you're using panels for now. Then just place those user controls onto your form(s) where your panels were.

Answer 2

In Winforms each form should handle it's own job. You should have a form for settings, another to show the current backups, etc.

If you want to stick with the single-form multiple groups you can create User Controls, as SnOrfus said, to separate the code. If you still end up with a ton of code on some classes you can have Partial classes to separate different code in to different files.

Partial classes may seem a good alternative but I'm only recommending that to you because you building a hobby project. For a bigger or more complex project you should use patterns to delegate the right work to the right objects, you can also switch to a new technology like WPF where is easier to use patterns like MVVM.