Borland resizing form during build?

[Wings]

Hi,
I have an application the builds perfectly well on one machine, yet for some reason the height and width are changed during the build process on another. The actual design values of height and width in the .dfm are changed. The application is designed to run at 1680 x 1050 (wide screen) and it builds correctly on my wide screen laptop. When built on another machine, also with the resolution set to 1680 x 1050, the main form is too large, stretching out past the bottom and right hand sides of the screen.

Has anyone run into anything like this before?

 

[2ffat]

I would look at the font sizes, etc. on the other machine. Maybe one is using a larger font so the form may try to correct for this.

I've never have a problem with machines with the same size but I do when I move the program to a machine that has a smaller size.

This is from the defunct BCBDEV.COM site. It includes the resizing routing I sometimes like to use:

Q: Design forms that work with both Large Fonts and Small Fonts

Answer

Many people have posted questions on the Borland newsgroups asking how to create forms that look right with both the small font and large font setting. Ensuring that forms to look correct on machines with different font settings can be a real pain. This FAQ summarizes a couple of strategies that I use to limit problems caused by the font settings.

In order to make sure your forms look correct with both font settings, try to stay in one of these three camps.
Camp A, the better camp:

* Design your program from a machine that uses small fonts
* Never open the project on a machine with large fonts
* Set Scaled to true for the form
* Set AutoScroll to false

With this strategy, the AutoScroll property is critical. When Scaled is true, the controls on a form expand by a ratio of 1.25 (120/96) when run on a large font machine. By expand I mean that their height and width are increased by a factor of 1.25. Left and Top are also increased by 25%. When the form's AutoScroll property is set to false, the size of the form also grows by the same factor. However, if AutoScroll is true, the form does not grow. When this happens, the resized and repositioned controls fall of the edge of the form (see Figure 3). When AutoScroll is on, the form apparently decides that showing the scroll bars is a better idea than resizing the form.

Tip Note: When you create a new form, Scaled is automatically set to true by default, which is good. Unfortunately, the AutoScale property also defaults to true. If you want your forms to appear correctly on a large font machine, you must actively turn off AutoScroll on all of your forms.

Here is something to keep in mind with respect to form scaling. When you design with the small font setting, your form will expand when run on a machine with large fonts. If you design your forms with the large font setting on, then you have to deal with forms that shrink when they are run on a small font machine. The problems that are caused by expanding forms are probably easier to deal with the problems of forms that shrink, which is what happens when you design at large fonts and run at small fonts. For this reason, if you use the Camp A technique, you should always work in the Form Designer with your system set to small fonts.

I have included some screen shots at the bottom of this FAQ to illustrate how these properties work. The screen shots are taken from an wizard like application that I wrote for a former employer, TRG (which is now Handera). Figure 1 shows what the form looks like on a machine with small fonts. The form's Scaled property is set to true and AutoScroll is off. Figure 2 shows the same program running on a large font machine. Although the form looks different, for the most part its appearance is acceptable. Notice how the picture of the PalmPilot appears to shrink. In reality, the picture has not changed in size. The form has grown by a factor of 120/96, giving the illusion that the picture is smaller. Figure 1 and Figure 2 are shown at their actual size so you can see how much the form grows on a large fonts system.

Figure 3 shows what happens when AutoScroll is left on. Notice how the controls are just chopped off. When AutoScroll is on, the VCL does not adjust the form's width or height to account for the expansion of the form's controls. Curiously enough, the scroll bars don't appear either, despite the fact that AutoScroll is true. Apparently, the scroll bars never appear when BorderStyle is set to bsDialog or bsSingle. Figure 4 shows what happens when AutoScroll is true and BorderStyle is set to bsSizeable. Hideous!! What's really funny is that this is the behavior that you get by default from a new form.

Camp B

* Design using large fonts or small fonts (but be consistent)
* Always set Scaled to false
* Set AutoScroll to false (it's just not a very useful property)
* Add code to your form that detects the font setting and adjusts properties as needed

This essentially turns off all scaling and leaves it up to you. It also tends to cause as many problems as it solves. However, one benefit of this strategy is that the width and height of your form remains constant regardless of the font setting. This is both a benefit and a hindrance.

The key to this strategy is to position the controls on your form so that they spaced far enough away from each other so they won't collide when run on a machine with large fonts. If you are going to follow the Camp B philosophy, you may actually want to use large fonts when designing your forms. This way you can rely on the fact that the size of text on your form will shrink if the user runs the form on a small font machine. Imagine that you have an autosized label on your form that just happens to be 120 pixels wide when designing the form on a large fonts system. When you run the same app on a small fonts system, the label will shrink to 96 pixels wide. Given that the width and height of the form are remaining constant (because Scaled is false) it is easier to deal with controls that are shrinking rather than controls that are expanding.

Another benefit of designing your forms on a large fonts system is the behavior of buttons. If Scaled is false, a button's width remains constant on both small fonts and large fonts systems. If you design your form with small fonts on, there is a chance that the button's text will outgrow the width of the button when run on a large font system. If you design on a large font system, then you can ensure that the text will fit. When you move the program to a small font system, the text will shrink inside the confines of the button.

If you use the Camp B strategy and you decide that you still want to design your forms on a small fonts system, you may run into trouble with labels not appearing correctly because of how they auto size. A single line label will never convert itself to multi-line if needs more room. It will only expand to the right. A mutli line label will only expand downward. These two facts may cause labels to collide when Scaled is false and you are designing your forms on a small fonts system.

If you can't design your form on a large fonts system, follow these suggestions to solve the problem with labels that collide. If single line labels collide with something, try setting AutoSize to false for the label. Then widen the label by a factor of 1.25 or more. This gives the text room to grow. If this expansion causes the label's boundary to collide with another control, then you need to convert to label to be multi-line. For multi-line labels, set AutoSize to false, keep WordWrap to true, and expand the Height of the label so it has a spare line or two. This allows the text to grow and fill up the rest of the label. At small fonts, these labels will seem farther apart than they do to a user running a large fonts.

One drawback to the Camp B strategy is that it takes more manual effort to get it right. Another issue is that if you design your forms from a large fonts system, your forms will look their best when run on other large fonts systems, but they may look sub optimal on a small fonts system. Because small fonts seems to be the more prevalent setting, it makes sense that forms should look their best on machines with small fonts. This is why I think the Camp A strategy is the better alternative.

Figure 5 shows the Camp B strategy in action. I have taken the the form from Figure 1 and simply turned the Scaled property off. Then I recompiled from a small fonts system and ran the app on a large fonts system. Figure 5 is a screenshot of the app running on a large fonts system. Notice how the form's size has remained constant. Also notice how the labels are all crowded together now. Another problem is that the text for the Cancel Upload button is too large for the width of the button control. Despite these problems, the form's appearance is acceptable (barely!).

In order to use the Camp B technique for my wizard form, some changes need to be made. I decided to try and design the form from a large font system first, and then run it on small font system. Figure 6 shows the new form at design time on the large font system. Figure 7 shows the new form running on a small font system.

Camp C

Tell users of large fonts to take a hike. This isn't always practical, but where I work now, it is I currently work in an IT department where all of the apps are for internal use. Because Visual C++ and MFC are no better at dealing with fonts (in fact they're worse), our IT department has specified that our programs (both MFC and BCB programs) will function correctly at 800x600, 16 bit high color, small fonts. If you are not running that, don't complain (I didn't make these rules by the way, but I don't seek their abolishment either).

If your software ends up on a shelf at CompUSA, this strategy might not be wise. The screen shots in this FAQ are from a past employer, Handera (they were called TRG when I worked for them). Handera currently makes a Palm OS handheld that competes with products from Palm and Handspring. In the past, they made expansion memory cards for the older line of PalmPilots. The program in the screen shots was a wizard like application that walked the user through process of configuring their memory card.

Because the progam was sold as a package to customers outside of the company, we did not have the luxury of simply forcing people to use small fonts. We had to design the program to function correctly on both small font and large fonts systems. We ended up using a combination of method A and method B.
Notes

Here are some other tips that I posted to the newsgroups.

1- Test until you are blue in the face. Usually, labels, edit controls, buttons, and scale themselves ok. Images appear to shrink on a large fonts system because the number of pixels per inch increases with large fonts. Space everything out so that the controls look ok when you switch to large fonts.

2- Sometimes, label's will run together on a large font machine, even though the text of the labels don't touch. The result is that one label will obscure another, despite the fact that there is plenty of clearance between the text in the labels. You can use the Send to back feature in the Form Designer to bring the obscured text back into view.

3- Whenever you create a new form, the BorderStyle is initially set to bsSizeable. For any form that looks and acts like a dialog box, you should change the border style to bsSingle or bsDialog.

4- Never hardcode the Width and Height of a form to an integer constant in code if the form's Scaled property is true. If you do, the form's client area will chop off some of the controls at runtime when you run the program on a large font machine. The result is exactly the same as what you see in Figure 3.

So instead of writing code like this:

__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
Width = 320;
Height = 240;
}

Write code that accounts for the fact that the form may need to scale

__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
Width = 320 * Screen->PixelsPerInch / 96;
Height = 240 * Screen->PixelsPerInch / 96;
}

Keep in mind that you only want to scale the values if the Scaled property is true. If it is false, you don't want to scale. Because of this, you might want to create a helper function for scaling the value.

Note that this suggestion also applies to setting the Left, Top, Width and Height properties of controls that are on your form. For example, you want to avoid writing code like this if Scaled is true:

__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
// put the label to the right and above the help button
Label1->Left = 150;
Label1->Top = 300;
}

The reason you want to avoid this practice is because the coordinate 150,300 shifts relative to everything else on the form when you move your program to a large font machine. On a small font machine, the coordinate 150,300 may have been in the middle of some open space in your form. On a large font machine, that same point might be smack in the middle of a button or some other control.

There are better ways to position the label. One method is to adjust the coordinates by the font size ratio. Another solution is to position the control relative to other controls around it. When the form scales on a large font machine, the relative coordinates will also scale.

__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
// Solution #1: scale the coordinates with the rest of the form.
Label1->Left = 150 * Screen->PixelsPerInch / 96;
Label1->Top = 300 * Screen->PixelsPerInch / 96;

// Solution #2: position relative to the help button.
Label1->Left = Button1->Left + Button1->Width + 10;
Label1->Top = Button1->Top - 15;

// Solution #2.01: Technically, the constants 10 and 15 should
// be scaled according to the font size.
Label1->Left = Button1->Left + Button1->Width + 10*Screen->PixelsPerInch/96;
Label1->Top = Button1->Top - 15*Screen->PixelsPerInch/96;
}


Copyright © 1997-2000 by Harold Howe.
All rights reserved.

Note that I didn't include the figures he refers to in the article.



James P. Cottingham
^{I'm number 1,229!
I'm number 1,229!}