Solved

Large vs Small Font Automatic Form Resizing

Posted on 1998-09-15
6
1,494 Views
Last Modified: 2013-12-02
I've coded several forms in delphi using small fonts.  However, when we tested the forms on a machine with Large fonts installed the controls on the form are not all repositioned properly. VB seems to handle this out of the box.  Does delphi?  If not, what can be done.  It seems that  in this day and age I should not have to write code to do this.
0
Comment
Question by:blitz051697
  • 3
  • 3
6 Comments
 
LVL 10

Accepted Solution

by:
viktornet earned 100 total points
ID: 1339760
Use this.......

Find the property that says Font->Pitch and set it to fpVariable

Regards,
Viktor Ivanov
0
 
LVL 1

Expert Comment

by:BlackDeath
ID: 1339761
aehm, viktor:
i'm afraid this is only for the character width not height, so e.g. your button labels are gonna be cut off anyway. or am i wrong?

Black Death.
0
 
LVL 1

Expert Comment

by:BlackDeath
ID: 1339762
whoops - i was quite wrong.

but to dodge possible troubles with this theme look at Borland Tip #2032:

(it's actually for form resizing, but there are lotsa good hints you just can't remember...)

When designing forms, it is sometimes helpful to write the code
so that the screen and all of its objects are displayed at the
same size no matter what the screen resolution is.  Here is
some code to show how that is done:
 
implementation
const
  ScreenWidth: LongInt = 800; {I designed my form in 800x600 mode.}
  ScreenHeight: LongInt = 600;
 
{$R *.DFM}
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  scaled := true;
  if (screen.width <> ScreenWidth) then
  begin
    height := longint(height) * longint(screen.height) div ScreenHeight;
    width := longint(width) * longint(screen.width) div ScreenWidth;

    scaleBy(screen.width, ScreenWidth);
  end;
end;
 
Then, you will want to have something that checks to see that
the font sizes are OK.  Before you change the font's size, you
would need to ensure the object actually has a font property.  
This can be done as follows:
 
uses typinfo;
 
var
  i: integer;
begin
  for i := componentCount - 1 downtto 0 do
    with components[i] do
    begin
      if GetPropInfo(ClassInfo, 'font') <> nil  then
        font.size := (NewFormWidth DIV OldFormWidth) * font.size;
    end;
end;
 
Note:  The following are issue to bear in mind when scaling
Delphi 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 TruueType 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.  OOtherwise, 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 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 thhe form is
scaled - you can't very well make components bigger without
also moving them over a bit.
 
sorry for this big chunk, but i think by only setting the Font.Pitch to fpVariable you _could_ get into some trouble...

Black Death.

0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 10

Expert Comment

by:viktornet
ID: 1339763
Yeah you are right..... The Pinch thing is best for fonts even thought it gives some effects to the comps....The ScaleBy() of the form can resize it so it fits on the screen, and it's the best to use for comps, use the Pinch method to make the Fonts resizable...One thing you have to remmember..You need to set the AutoSize of the form to false, otherwise the form won't fit into the screen and will get those scroll bars...You don;t want to do that......Right??

Regards,
Viktor IVanov
0
 
LVL 1

Expert Comment

by:BlackDeath
ID: 1339764
right, vik, thanx.
Black Death.
0
 
LVL 10

Expert Comment

by:viktornet
ID: 1339765
What's up???

Planning to accept or reject my answer???

Regards,
Viktor Ivanov
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
Objective: - This article will help user in how to convert their numeric value become words. How to use 1. You can copy this code in your Unit as function 2. than you can perform your function by type this code The Code   (CODE) The Im…
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now