Главная страница | назад





Article #16054: Scaling BCB Applications

 Question and Answer Database

FAQ1054C.txt   Scaling BCB Applications
Category   :VCL
Platform    :All
Product    :C++Builder  1.x

Question:

What issues do I need to be aware of when developing 
applications that will be run on different screen 
resolutions (form scaling)?

Answer:

The following are issue to bear in mind when scaling 
BCB applications (forms) on different screen resolutions?

* Decide early on 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.  MS San Serif is an ok alternate, but remember that 
  it is still a bitmapped font.  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. 
  This font may not match the same size of the original 
  font any may cause problems.

* 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 1280x1024 screen - and completely off the 640x480 
  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.

* 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.

* Don't change the PixelsPerInch property of the form, 
  period.

* 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 no 
  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.

7/2/98 10:32:32 AM
 

Last Modified: 01-SEP-99