The Old Joel on Software Forum: Part 3 (of 5)

Resizing Forms

I'm wondering how you guys resize your forms. Do you expand all fields on the form or just one. Maybe you don't expand any fields and simply center everything? Some people think this is an easy thing to accomplish, but designing an interface to accomodate expanding fields and scrollbars etc, in practice, isn't so easy. Any tips, advice, flames etc?

Tuesday, December 2, 2003

In a VB6 app, mostly I only resize one control, often a DataGrid or something.
Anything below or to the right of the resizable control is anchored to the bottom or right of the form. I have a utility class FormSizer which is included on every resizable form to handle resizing, anchoring etc.

Tuesday, December 2, 2003

Depends on the application, but by and large forms that gain a benefit from resizing contain some kind of grid (resizing the font I don't take to be the same kind of thing at all).

With that in mind I allow grids (edit boxes as well) to expand with the form with the fixed size fields moving relatively with the borders.

Simon Lucy
Tuesday, December 2, 2003

I wrote a program to allow me to bind control edges to other control edges (or parent window edges, etc) with variable elasticity (so completely rigid bindings are used for the most frequent kind of resizing tasks -- keeping control edges some fixed distance from other control edges and the edge of the parent window).

K
Tuesday, December 2, 2003

Oh and scrollbars are fine on controls but not on forms.

Simon Lucy
Tuesday, December 2, 2003

I just let BorderLayout handle things for me (in Java and .NET)! Having to manually resizing your forms seems so... 1994.

Fred
Tuesday, December 2, 2003

I dynamically resize all objects on the form and (of course) the font size. Also helps if you use a True Type font so that it's resizable to ANY size.

One issue is that the form might change it's aspect ratio (x/y ratio) which can cause probems for resizing fonts.

I resize the fonts by whichever dimension is reduced more. (I.e., if width reduces by a bigger % than height, then I'd reduce font by that width % reduction).

There's source code examples out there for VB 3 and 6 (which I use).

Try source code planet (or planet source code).
Google for it.

Entrepreneur
Tuesday, December 2, 2003

Just binding particular edges of controls to dialog edges works surprisingly well. It doesn't take long to write code that will do this based on the original layout of the dialog, which is unfortunately your only guide if you're stuck using the VC++ dialog editor.

Non-resizable dialogs suck. Quite why there's no system in Windows for this is beyond me, but there you go.

Insert half smiley here.
Tuesday, December 2, 2003

Ummm, resizing fonts when the user doesn't want that is more than a bad idea. Resizing fonts when all the user does is resize the dialog is a worse one.

Respect the metrics that the use has chosen, they may not have chosen them for any particular reason but you better believe that the ones that need a particular size damn well want it to stay the way they set it.

On the other hand giving the user separate control of the font size is a good thing (and then resizing the form appropriately), as in CSS styled forms.

Simon Lucy
Tuesday, December 2, 2003

Some good rules of thumb:

1. Controls that scroll, wrap, or chop content should resize in the direction of the scrolling, wrapping, or chopping.

See the Address bar text field, the main content area, and the main pane of the status bar in Internet Explorer for examples of this.

The point of resizing a window is to show or hide more content. Since content is hidden by controls that scroll, wrap, or chop, they should be the main candidates for resizing.

2. When a conflict occurs between two controls qualifying for #1, pick the main one and only resize that (and ideally provide a separate mechanism for resizing the other one).

See the Windows Explorer left folder tree and right file area.

When resizing a window, it's probably the main content that the user wants to see more of so it should be the main content that benefits from the resizing.

3. Any dimensions that don't scroll, wrap, or chop should be preserved (such as both directions on a button) but the control should be moved to preserve the same relative position in the window (and obviously should move if it's going to conflict with a resized control).

See the Go button in the Internet Explorer Address bar or the Save/Cancel buttons on a standard open/save file dialog.

Try documenting the location of OK/Cancel buttons that move to preserve their relative positions (bottom right corner) on a window that resizes. Then try documenting where they are on a window that resizes and they preserve their absolute positions (bottom right corner, or maybe bottom middle, or if the window is really big then bottom left corner, or maybe somewhere in between one of those, blah blah blah).

SomeBody
Tuesday, December 2, 2003