Author: Tomas Rutkauskas

I'm designing my forms for multiple screen resolutions and I'm going through a 
major problem. I'm designing at 800x600 and when the screen resolution increases 
the form looks Ok, but when it decreases (640x480) some of my components get wild. 
They don't seem to follow the same pattern when they get smaller.

Answer:

Solve 1:

I think you are using the wrong approach. If you just proportionally resize your 
form and anything on it you do not usually meet the users requirements. If he uses 
a higher screen resolution he usually wants to see more information on the screen, 
not just the same information displayed larger.

I design forms always in large font mode (120 dpi), use only true-type fonts (Arial 
8 or 9 pt as form default) and set the forms Scaled property to false. If the form 
has controls that can benefit from being resized larger to show more information 
(memos and grids mostly) I use the bsSizeable border style and set the controls 
Anchors (or use Align) to make them track changes in the form size automatically. 
If the controls cannot be resized with any benefit the form gets the bsDialog 
border style. If the form is larger than 600x400 I conduct a test for the workarea 
size (SystemParametersInfo(SPI_GETWORKAREA ...)) and if it is smaller than the form 
the form is resized to the workarea size, its AutoScroll property is set to True so 
it sprouts scrollbars. This may not look too great but it makes all of the controls 
accessible to the user and is far better than proportionally shrinking the form and 
end up with a font size that is practically unreadable. The Windows font mapper 
also deviates from strict proportionality for smaller font sizes, these are 
rendered a bit larger than one would expect to improve legibility. And if you use 
non-truetype fonts the mapper may even substitute a larger font since the one you 
require is not available in the requested size. This totally screws up the form 
layout if you use controls with Autosize true (edit control standard, for example).


Solve 2:

From Borland (issues to bear in mind when scaling Delphi forms on different screen 
resolutions):

Decide early in the form design stage whether you're going to allow the form to be 
scaled or not. The advantage of not scaling is that nothing changes at runtime. The 
disadvantage of not scaling is that nothing changes at runtime (your form may be 
far too small or too large to read on some systems if it is not scaled).
If you're NOT going to scale the form, set Scaled to False. Otherwise, set the 
Form's Scaled property to True.
Set AutoScroll to False. AutoScroll = True means 'don't change the form's frame 
size at runtime' which doesn't look good when the form's contents do change size.
Set the form's font to a scaleable TrueType font, like Arial. Only Arial will give 
you a font within a pixel of the desired height. NOTE: If the font used in an 
application is not installed on the target computer, then Windows will select an 
alternative font within the same font family to use instead.
Set the form's Position property to something other than poDesigned. poDesigned 
leaves the form where you left it at design time, which for me always winds up way 
off to the left on my 1280 x 1024 screen - and completely off the 640 x 480 screen.
Don't crowd controls on the form - leave at least 4 pixels between controls, so 
that a one pixel change in border locations (due to scaling) won't show up as ugly 
overlapping controls.
For single line labels that are alLeft or alRight aligned, set AutoSize to True. 
Otherwise, set AutoSize to False.
Make sure there is enough blank space in a label component to allow for font width 
changes - a blank space that is 25% of the length of the current string display 
length is a little too much, but safe. (You'll need at least 30% expansion space 
for string labels if you plan to translate your app into other languages) If 
AutoSize is False, make sure you actually set the label width appropriately. If 
AutoSize is True, make sure there is enough room for the label to grow on its own.
In multi-line, word-wrapped labels, leave at least one line of blank space at the 
bottom. You'll need this to catch the overflow when the text wraps differently when 
the font width changes with scaling. Don't assume that because you're using large 
fonts, you don't have to allow for text overflow - somebody else's large fonts may 
be larger than yours!
Be careful about opening a project in the IDE at different resolutions. The form's 
PixelsPerInch property will be modified as soon as the form is opened, and will be 
saved to the DFM if you save the project. It's best to test the app by running it 
standalone, and edit the form at only one resolution. Editing at varying 
resolutions and font sizes invites component drift and sizing problems. Make sure 
that you set your PixelsPerInch for all your forms to 120. It defaults at 96, which 
causes scaling problems at a lower resolution.
Speaking of component drift, don't rescale a form multiple times, at design time or 
a runtime. Each rescaling introduces roundoff errors which accumulate very quickly 
since coordinates are strictly integral. As fractional amounts are truncated off 
control's origins and sizes with each successive rescaling, the controls will 
appear to creep northwest and get smaller. If you want to allow your users to 
rescale the form any number of times, start with a freshly loaded/created form 
before each scaling, so that scaling errors do not accumulate.
In general, it is not necessary to design forms at any particular resolution, but 
it is crucial that you review their appearance at 640x480 with small fonts and 
large, and at a high-resolution with small fonts and large before releasing your 
app. This should be part of your regular system compatibility testing checklist.
Pay close attention to any components that are essentially single-line TMemos - 
things like TDBLookupCombo. The Windows multi-line edit control always shows only 
whole lines of text - if the control is too short for its font, a TMemo will show 
nothing at all (a TEdit will show clipped text). For such components, it's better 
to make them a few pixels too large than to be one pixel too small and show not 
text at all.
Keep in mind that all scaling is proportional to the difference in the font height 
between runtime and design time, NOT the pixel resolution or screen size. Remember 
also that the origins of your controls will be changed when the form is scaled - 
you can't very well make components bigger without also moving them over a bit.


Solve 3:

To ensure that your projects will work with both large and small fonts you want to 
do exactly this: Develop using small font with TForm.AutoScroll = False. This is 
how we develop the IDE itself and have so for years


Solve 4:

On form scaling and the large fonts/ small fonts issue:

This is usually a problem of large fonts (120 dpi) vs small fonts (96 dpi) 
settings. The user can change these settings as part of the display options in 
control panel. You can check the settings at runtime by looking at 
Screen.PixelsPerInch.

Different ways have been suggested to create forms that will work well on both 
settings. The most important one is to use TrueType fonts (like Arial) only in your 
forms. Ms SansSerif, the default, is TT on NT but not on Win9x!

Option 1: Design on small fonts, leave the forms Scaled propery set to true, set 
forms AutoScroll to false, leave a little extra space between controls so they can 
grow a bit under large fonts without colliding with each other. This is said to be 
the method Borland uses for the Delphi IDE itself. When you test on large fonts 
never save the project there! If you save such a form under large fonts it will 
become distorted under small fonts!

Option 2: Design on large fonts and set Scaled to false. This is my favourite since 
large fonts is my default setting (I am myopic). Again take care never to save the 
project under small fonts or the forms will become distorted.

A final issue you may need to take care of is the users screen size (in pixels). If 
you design your forms to run well on 800x600 the user will have a problem if he is 
running 640x480. So your forms should check the screen size (Screen.Width, 
Screen.Height) in their OnCreate handler. If the screen is too small for the form 
the form shoulds resize itself to the screen size (or better the workarea size, see 
SystemParametersInfo( SPI_GETWORKAREA) and set its AutoScroll property to true. It 
will then automatically sprout scrollbars, so the user can at least access all 
parts of the form. Trying to rescale the form to the smaller screen size will 
almost never result in a usable form, so I don't consider this an option.