Delphi apps using Windows Large Fonts

[Diego Barros]

Hi all,

I was wondering how others deal with Delphi applications while Windows
is set to use large fonts (at 120 DPI)?

On a Dell notebook, with a resolution of around 1600 x 1200 (or there
abouts), the application looks tiny, even while using Large Fonts. Some
forms also have buttons cut off and are no longer visible (i.e. they are
off the side of visible area of the form). Any help would be appreciated.

I also noticed that the higher Windows XP window title bars affect the
form. I designed a form on Windows XP, but using the Classic theme, and
when I ran the application under the XP theme, buttons that sat along
the bottom of the form were not slighty cut off or right against the
bottom edge of the form. How can this be avoided?

Thanks in advance.

Cheers,
Diego

[TObject]

Post by Diego Barros
I was wondering how others deal with Delphi applications while Windows
is set to use large fonts (at 120 DPI)?

Good question.

There are different ways to approach the issue.

I personally use this simple method: I develop VCL applications
using large fonts setting on my computer monitor.

Here are some of the relevant form properties I use:

AutoScroll = False
Scaled = False
PixelsPerInch = 120

[Colin Wilson]

Post by TObject
Scaled = False

I use 'Scaled = False' for the main form, and 'Scaled = True' for
dialog boxes. Borland do the same - I checked with my resource editor.

I never use 'AutoScroll'!

[Crazy Horse's crazier little brother]

Post by Colin Wilson
I use 'Scaled = False' for the main form, and 'Scaled = True' for
dialog boxes. Borland do the same - I checked with my resource editor.

Why would one be better for one (main) and the other be better for the other
(dialogs)?

[JED]

Post by Colin Wilson

Post by TObject
Scaled = False

I use 'Scaled = False' for the main form, and 'Scaled = True' for
dialog boxes. Borland do the same - I checked with my resource editor.
I never use 'AutoScroll'!

The problem with Scaled = True for dialog boxes is if you have sizeable
dialogs (not bsDialog) and anchored controls (like Bottom/Right) then
the dialog gets all screwed up by the IDE in Delphi 2005. Very
frustrating.

The whole developing for large fonts is starting to become a huge issue
because people are buying laptops that have large fonts set as default
because they have such huge resolutions (I still run my 1920x1200 at
96dpi).

It's up to Borland to give us a solution that works 100% all the time.
Scaled True works pretty well except when you have anchored controls.
I'd like to see that fixed.

[Nick Hodges [TeamB]]

Post by JED
It's up to Borland to give us a solution that works 100% all the time.

The one that Borland uses for Delphi itself appears to work 100% of the
time.

http://tinyurl.com/4vyrm

[JED]

Post by Nick Hodges [TeamB]

Post by JED
It's up to Borland to give us a solution that works 100% all the time.

The one that Borland uses for Delphi itself appears to work 100% of
the time.
http://tinyurl.com/4vyrm

Perhaps, but we don't know what else they are doing behind the scenes
to make it "appear" to be working fine.

A couple of items to prove that it doesn't work fine for some of us.

Defect 9984
Form design changes each time project is opened
http://qc.borland.com/wc/qcmain.aspx?d=9984


Try the following:

Win32 personality.

1. New Win32 project
2. Drop a button on the form in the bottom right corner
3. Set anchors to [akRight, akBottom]
4. Set form scaled property to FALSE
5. close the form
6. reopen the form - WTH the form size has changed.
7. move the button to the corner again
8. close and reopen form - form size has changed again.

This does not happen with Delphi 7.


I will give the AutoScroll = False a try (later). Why isn't the
default False if this works then? Strange...

[Nick Hodges [TeamB]]

Post by JED
Perhaps, but we don't know what else they are doing behind the scenes
to make it "appear" to be working fine.

Steve has repeatedly said that that's all they do.

Post by JED
This does not happen with Delphi 7.

Things may have changed in D2005.

[JED]

Post by Nick Hodges [TeamB]

Post by JED
Perhaps, but we don't know what else they are doing behind the
scenes to make it "appear" to be working fine.

Steve has repeatedly said that that's all they do.

Post by JED
This does not happen with Delphi 7.

Things may have changed in D2005.

Interesting. While it might seem I'm just arguing for the sake of it
here is the TAppBuilder dfm from Colin Wilsons newly updated Resource
Explorer (http://www.wilsonc.demon.co.uk/delphi.htm).

If you run delphi under large fonts you will also notice that some
dialogs scale and some don't. I haven't ran delphi for an extended
period of time under large fonts (I was just testing something else)
but that is what I recall seeing.

As I mentioned, I will give AutoScroll = False a chance. I sure hope
that does work for me. Perhaps we need a layout control that Java has
had for ages and WinForms 2 is getting.

open bds.exe

inherited AppBuilder: TAppBuilder
HorzScrollBar.Increment = 48
VertScrollBar.Increment = 6
AutoScroll = False
Caption = ' '
ClientHeight = 99
ClientWidth = 788
Menu = MainMenu1
Scaled = False
ScreenSnap = True
OnActivate = FormActivate
OnClose = FormClose
OnCloseQuery = WindowCloseQuery
OnConstrainedResize = FormConstrainedResize
OnShortCut = FormShortCut
PixelsPerInch = 96
TextHeight = 13

[Colin Wilson]

Post by JED

Post by Nick Hodges [TeamB]

Post by JED
This does not happen with Delphi 7.

Things may have changed in D2005.

Interesting.

After reading this thread, I switch to large fonts and fired up the
latest D2005 version of XanaNews. The dialog boxes in that are mostly
all resizable, with Scaled=True, and lots of inherited forms, anchors,
align and constraints.

It's basically OK. The anchors and aligns all seem right. *But* the
'constraints' are now all to small, so its now possible to resize the
dialogs so that the controls don't fit.

I think I'll have to do some experimenting wih manually scalling
constraints in the dialog's constructors etc.

[JED]

Post by Colin Wilson
After reading this thread, I switch to large fonts and fired up the
latest D2005 version of XanaNews. The dialog boxes in that are mostly
all resizable, with Scaled=True, and lots of inherited forms, anchors,
align and constraints.
It's basically OK. The anchors and aligns all seem right. But the
'constraints' are now all to small, so its now possible to resize the
dialogs so that the controls don't fit.
I think I'll have to do some experimenting wih manually scalling
constraints in the dialog's constructors etc.

One thing I have just noticed is that if you owner draw listboxes or
checkboxes (and possibly comboboxes) I changed the style to
lbOwnerDrawVariable and populated the OnMeasureItem event with

Height := abs(Font.Height);

Naturally if the listbox is already Variable, then further calculations
are required in the OnMeasureItem event.

[William Meyer]

Post by Colin Wilson
I think I'll have to do some experimenting wih manually scalling
constraints in the dialog's constructors etc.

Be careful not to open the app in *design* mode with large fonts. Or at
least, it used to be the case that doing so would automagically alter
all the forms, leaving a tremendous amount of repair to be done by hand.

[JED]

Post by Nick Hodges [TeamB]
Steve has repeatedly said that that's all they do.

RE: AutoScroll=False

close but no cigar unfortunately.

I have a common dialog panel component that is a TCustomPanel decendant
that has 2 buttons, a bevel and a checkbox on it. It defaults to being
alBottom.

If I drop that onto a form with some other controls (couple of labels,
edits and a memo - anchored so it resizes nicely), the dialog panels
components don't get moved correctly.

If I create the panel at runtime it doesn't get resized at all!

However if I delete my component and simulate it with a bottom aligned
panel, 2 buttons and a bevel (the checkbox is invisible by default)
then it looks really good.

So why doesn't it resize my component correctly?

I've uploaded a screenshot (in attachments group) of my test apps and
how the different properties changed the look...

Note: my normal fonts pc is XP, large fonts pc runs win2000

1. No changes to properties.
Created on normal fonts pc. (as all apps were)
Run on Large Fonts pc. (as all apps were)
2. Scaled = False
3. AutoScroll=False
My component replaced with the separate comps that make it up
4. AutoScroll=False
With my footer component
5. AutoScroll=False
My footer component created at run time (in OnCreate) - Look how small
it is!!!

[Nick Hodges [TeamB]]

Post by JED
close but no cigar unfortunately.

The other thing is to always develop in small fonts.

[JED]

Post by Nick Hodges [TeamB]
The other thing is to always develop in small fonts.

yeah I do

[Holger Flick]

Hi Nick,

Post by Nick Hodges [TeamB]
The other thing is to always develop in small fonts.

I do and users complained that they had stuff like "D..." in the
toolbar. For me it was "Details". Users switched to "small fonts" and
it was all fine. Except that the users complain that all other apps on
their system are tough to read :-)

--
Holger

[JED]

Maybe the D7 workaround still works. Keep your borderstyle at a fixed
size and set it to sizeable in the form's oncreate event.

Interesting I'll try that.

[Jan Derk]

Post by JED
Interesting I'll try that.

I note from your other post that I am talking about another issue.

In D4, D5 , D6 & D7 you do not want to to have anchors to the right and
bottom on sizable forms. All will look good on your development
computer, but the controls will be mispositioned if your customer runs
your application at a different font size.

Q1083
Q1113
Q2127

Jan Derk

[JED]

Post by Jan Derk

Post by JED
Interesting I'll try that.

I note from your other post that I am talking about another issue.
In D4, D5 , D6 & D7 you do not want to to have anchors to the right
and bottom on sizable forms. All will look good on your development
computer, but the controls will be mispositioned if your customer
runs your application at a different font size.
Q1083
Q1113
Q2127
Jan Derk

So how are people anchoring there buttons on sizeable forms then?
Do they set the anchors in the OnCreate?

Interesting 2127 seems to be what I have reproduced with Delphi 2005.
I couldn't reproduce that in D7.

[Jan Derk]

Post by JED

Post by Jan Derk
In D4, D5 , D6 & D7 you do not want to to have anchors to the right
and bottom on sizable forms. All will look good on your development
computer, but the controls will be mispositioned if your customer
runs your application at a different font size.
Q1083
Q1113
Q2127

So how are people anchoring there buttons on sizeable forms then?
Do they set the anchors in the OnCreate?

You leave the forms borderstyle at bsDialog at design time. In the
form's onCreate event you then add:

BorderStyle := bsSizeable;

If you do it like that you can put your anchors right and bottom
aligned. If you don't, many of your customers will look at one ugly
window or have controls outside the visible window area.

The bug only appears if you set TForm.Position to some setting where
Windows decides on the size of your resizeable window like poDefault. My
guess is that Delphi does not apply the scaling factor when compensating
for the new form width and height settings when positioning right and
bottom aligned components, which is why setting the resizeable
borderstyle in oncreate works. But this is all from the top of my head
digging into memories from years ago.

It reminds me of another issue though: which genius decided that having
poDesigned as default for TForm.Position is a good thing?

Jan Derk

[Colin Wilson]

Post by Jan Derk
It reminds me of another issue though: which genius decided that
having poDesigned as default for TForm.Position is a good thing?

Ha! That one's bugged me for years. At least you know you've always
got to change it!

[JED]

Post by Colin Wilson

Post by Jan Derk
It reminds me of another issue though: which genius decided that
having poDesigned as default for TForm.Position is a good thing?

Ha! That one's bugged me for years. At least you know you've always
got to change it!

There is a reason actually for this.

[Jan Derk]

Post by JED
The problem with Scaled = True for dialog boxes is if you have sizeable
dialogs (not bsDialog) and anchored controls (like Bottom/Right) then
the dialog gets all screwed up by the IDE in Delphi 2005. Very
frustrating.

That bug has been among us for centuries, well at least years. I tried
to report it a few times but gave up after reports not being openened
and when they were opened, being closed again by some "Could not
replicate" Borlander.

Maybe the D7 workaround still works. Keep your borderstyle at a fixed
size and set it to sizeable in the form's oncreate event.

Jan Derk

[Andrew Rybenkov]

Post by TObject
There are different ways to approach the issue.
I personally use this simple method: I develop VCL applications
using large fonts setting on my computer monitor.

I follow a market leader - Adobe Photoshop - and ignore large fonts totally.
In case of rare combination - bad sight + bad monitor - well, there are accessability
utilities in Windows.


--
Andrew Rybenkov.

[Jan Derk]

Post by Andrew Rybenkov
I follow a market leader - Adobe Photoshop - and ignore large fonts totally.
In case of rare combination - bad sight + bad monitor - well, there are accessability
utilities in Windows.

Or your customer can buy your competitor's product which does look good
on their screen. Now that new technologies bring us more and more
ultra-low and high dpi screens, proper scaling is becoming more
important than ever.

You can, of course, ignore all of the above if your application holds a
similar monopoly position as Adobe Photoshop.

Jan Derk

[Andrew Rybenkov]

Post by Jan Derk
Or your customer can buy your competitor's product which does look good
on their screen.

if that customer (bad sight-bad monitor) is so idiotic to run it on high resolutions (instead, say,
800x600), then I, most certainly, do not want him.
In my kind of business I had such customers that (if I knew it beforehand) I would pay myself to them
they did not appear on my horizon.

Post by Jan Derk
Now that new technologies bring us more and more
ultra-low and high dpi screens, proper scaling is becoming more
important than ever.

not a bit.
Again if a person has problems with high resolutions he should not run them.

Post by Jan Derk
You can, of course, ignore all of the above if your application holds a
similar monopoly position as Adobe Photoshop.

I do not agree PS is a monopoly.


--
Andrew Rybenkov.

[Colin Wilson]

Post by Andrew Rybenkov
if that customer (bad sight-bad monitor) is so idiotic to run it on
high resolutions (instead, say, 800x600), then I, most certainly, do
not want him.

It's not *so* idiotic though. Often people want to be able to browse
the web (for instance) with large, readable text; but without all the
images blown up huge.

[Andrew Rybenkov]

Post by Colin Wilson
It's not *so* idiotic though. Often people want to be able to browse
the web (for instance) with large, readable text; but without all the
images blown up huge.

Sure, but I talked specially about bad sight/bad monitor combination.



--
Andrew Rybenkov.