Resizing a Form has always been a pain in the rectum...
Think really hard for a second about how layout logic works... Oh, not that hard, you're starting to smoke. Here, how about I think about it for you and then you can point out where you have a difference of opinion... That works better for me anyway. To start, layouts come in several different formats that will help use discuss the issues at hand. Here are several different formats that I can think of off the top of my head.
- Fixed or Explicit Layouts - This is the most rigid layout type and it involves placing the controls precisely where you want them on the form and precisely sizing them. The main problem with fixed layouts is that you start to run into trouble as soon as you allow the form to resize. Either you have to augment the explicit layout with some additional code, or simply allow for the controls to stay in their place and forget the fact that your application looks ugly now.
- Flow Layouts - Flow layouts are a bit more flexible. This is most similar to the way text wraps or flows in either your text editor or an html page. Think of each word as a control, and pretend you are simply trying to fit as many words per line as possible. Flow layouts change position, but not the size of an element. In this manner, if an element fits on the line it goes there, but if it would have to be resized, even if it could be, it won't. When forms are made extremely wide flow layouts tend to look terrible. Even worse, if the elements are all different sizes then you wind up with a jagged right hand edge. The answer here is justification where the appropriate amount of border space is placed in between so that all controls are flush.
- Tabular Layouts - These are probably the most often used. They can either be versatile and allow a variable number of columns depending on the row, or fixed, where each row has the same number of columns. Some columns are given a specific size, a percentage size, or allowed to expand to fill the remaining space. The closest equivalent is the html table elements. Tables don't allow for complex layouts without having a series of place-holder columns. Each place-holder column added allows more and more freedom in placement, but at the same time, the more you add, the closer you are to simply using pixels (pixels are indeed a tabular layout mechanism).
- Composite Layouts - Composite layouts are based around a hierarchy of nested layout types. At the top level of an application you often have a very specific fixed layout, with perhaps some resizing occuring between the few top-level elements. Outlook is a great example with its various configurable panes or windows. Within the panes more layout occurs. You can custom configure this lower level layout to be whatever you'd like, but it is easiest to support a two or three column tabular layout. Flow layouts are also popular.
When does layout go from fun to work? Well, laying out things in the designer is fun, but got forbid you have to do it in code. Code requires numerous properties be set on each control, that the control z-order be set properly, and that the programmer have a great grasp on exactly what the project looks like from a UI stand-point. Many programmers don't have this spatial visualization capability, hence the reason for sticking with the designer and forgetting about code based layouts.
A good mixture is required in my opinion. Certain things are easier to lay out in code and others much easier in the designer. Run-time UI generation is a requirement of many application as well that change dynamically based on configuration or data.
So how does that come into play during a resize? Well, someone has to write code. Explicit layouts look terrible when you resize them. They are based on precision and changing the precise sizes and locations of elements programmatically results in some nasty issues. Round-off errors also make for poor aggregate layout decisions and many times you can reset the form size and see a slightly different layout. Normally it is just good enough, but that doesn't fly with me. Flow and Tabular layouts are a bit better, they are based on more configurable and dynamic information and so they tend to resize much better. Composite layouts are the best because they localize the layout process to specific regions, and they allow you to configure each area most appropriately so that it looks best when things change.
Layout isn't just about the big scene, there are also some small scene items that have to be taken care of. Most layout systems don't control their container, in turn their container controls them. However, controlling minimum sizes at the container level is foolhardy. You don't know how small an area can be until you understand how small the control itself can be. Each layout manager should be able to determine what a safe minimum size is and a higher level component at the form level should aggregate this data in order to size the form appropriately. This disables scenarios where the user can screw the system.
I'm going to hit one more type of layout though. I call this the bump layout and it is a very programmer oriented approach. At the lowest level a bump layout is based around the first control placed on the form. As controls are added, using bump commands, a global bounding region is updated that can then be use to set the size of the form. This is a mixture of fixed layout programming, but is code oriented rather than designer oriented. A sample bump layout might be as follows.
Layout(firstControl, left, right, width, height); // Prevents property setting
RightAlign(RelatedSize(firstControl, secondControl)); // relates second control to first control, returns second control
BottomAlign(RelatedSize(firstControl, thirdControl)); // same, you can wrap all sizings into a single call if you'd like
I call the above a bump layout because you bump the location of a control to an offset based on an existing control... Bump layouts have the ability to be turned easily into resizable layouts because everything is based around the first control. The first control could be sized based on the current form size, and then the rest of the layout just works correctly. You can also support FlowLayout and TableLayout quite easily by using the results of bumps. An overflow bump would put a control partially off the screen and so you can change the bump from a RightAlign to a BottomAlign. For tabular layouts you can align your columns based on the top row and then use those in bumps to generate the rest of the layout information.
I plan on putting some code behind this. There is some interest in programmatic layouts and I'm sure I could add some of my code to Whidbey and augment the existing layouts provided by the Windows Forms team. One of my more interesting layout patterns has been the radial layout, of which I'm very proud, that not only gives each control information about location based on a radius and angle, but also allows the control access to the layout information so that it can properly rotate and possibly resize itself to make sure its rotated contents fit within it's area. A second layout pattern, the markup layout pattern, is more based around the concepts of using an html table format, and an ID that matches the Name of specific controls. Using this layout mechanism is different from the more extensive XAML layout because it only focuses on a control's layout and as such can be easily added to an existing system.