Is there a quick and effective way of applying a global Font to be used in a project?

By this I mean I would like to set a specific Font name that all controls in my project will use such as TButton, TEdit, TLabel etc.

Typically setting the Font for the Form rather than a specific control will change all the controls on that Form to the Font specified.

There is a slight issue with this however, if you have manually changed a Font on a specific control, then setting the Font by the Form will no longer update those controls that have previously been changed manually.

Idea 1

I was thinking of using a For loop and iterating through each component on my Forms and setting the Font this way, such as:

If you change control's font manually you also set its ParentFont property to False; set it True to return default (Parent) font
–
user246408May 14 '12 at 18:10

1

Sneaky, I did not realise this property had been getting changed!
–
user1175743May 14 '12 at 18:15

9

Before creating any forms, set Application.DefaultFont.Name := 'MS Sans Serif'; With the ParentFont set to true in your forms as Serg points out. To set the font in the message dialogs, set the Screen.MessageFont.Nameproperty.
–
LU RDMay 14 '12 at 18:16

1

If you ever need to do this at runtime, you can iterate form components as you did above and check to see which components have the Font property published using the IsPublishedProp(Components[i], 'Font') method from the TypInfo unit. Then, you can hack TControl to set the component's Font property, i.e.,
–
Max WilliamsMay 14 '12 at 18:36

5

If you strip all Font and ParentFont properties from your .dfm files then ParentFont defaults to True, and it's all good.
–
David HeffernanMay 14 '12 at 18:43

3 Answers
3

As discussed in the comments, the key to this is the ParentFont property. This property is defined at various points in the VCL hierarchy. If you set ParentFont to be True for all components in the chain, then you can change the fonts for the entire application simply by modifying

Application.DefaultFont

By default most components set ParentFont to True and so you have nothing to do. The odd one out though is TForm. A brand new default form has ParentFont set to False. This is somewhat disappointing but I suspect reflects the fact that the original designers of the VCL did not anticipate this and that ParentFont was grafted on relatively late in the development of the VCL.

No matter, in an ideal world, all forms in your application should be derived from a common base class that you control. If that is so then you can simply make the change there, set ParentFont to be True, make sure no explicit font settings are applied to any components on you forms, and you are golden. Control the entire application's fonts through a single property. If you don't have a common base class for your forms, here's an ideal time to add it. If you don't want to do that then you need to set ParentFont for each form.

Other related properties are Screen.MessageFont and Screen.MenuFont. These provide global control over the fonts used in message boxes and menus. However, recent versions of Delphi have handed back to Windows control over the painting of message boxes and menus and so these properties have no effect.

There is nothing really to add to what you and others have commented on already. Wouldn't it be great though if there was an option in the Project Options to set a Font style and apply it to the project, in the same way that Application.DefaultFont works - if like me been unaware of this built-in function, having the visual setting to change the font globally would make it much easier. Anyway I accept your answer because the information is well written, and +1 for highlighting message and menus.
–
user1175743May 14 '12 at 21:46

8

Remember that VCL forms are not "layout managed" like Swing (java) or WPF (C#/.net) and that changing fonts at runtime leads to a perfect hell of font-clipping, and makes your UI an unreadable mess. Good luck. There is no practical way to change an applications fonts without reviewing the results by hand, form by form, for readability.
–
Warren PMay 14 '12 at 23:47

3

@Warren that's a good point and I intended to mention it in my answer, but forgot. In my app, I show fonts in either Tahoma 8 for XP or Segoe UI 9 for Vista+. This needs calls to ChangeScale to change form layout. But yes you have to check the forms in both variants. So long as you don't cram your labels hard up against each other, there's never a problem. ParentFont works wonders in all of this.
–
David HeffernanMay 15 '12 at 6:37

4

I am going to try this myself and will probably blog about the results.
–
Warren PMay 15 '12 at 23:28

2

+1 for "all forms in your application should be derived from a common base class that you control".
–
kobikMay 17 '12 at 16:27

It is not ideal coding such a thing, but your answer is useful non the less :)
–
user1175743May 14 '12 at 21:41

3

Unfortunately not all font properties are named 'Font'...
–
Marjan VenemaMay 15 '12 at 6:26

@MarjanVenema It was only intended as an illustration. If you have non-VCL components deploying other font property names, you will have to expand the function with those property names, of course. However the main point in this discussion is the point mentioned by Warren P in the comment above: Usually it's not viable to alter font properties runtime like this, because it alters alignments, introduces font-clipping, etc.
–
EllingMay 15 '12 at 7:49

The real key, as was mentioned, is to ensure that all your forms descend from your own application base form.

Then, you can view each form and button etc, and review the properties, where any modified font property should be displayed in bold, and is easily identified. Most properties have a "Revert to inherited" menu choice. This should essentially undo any previous selection, without having to go to the text version for editting. (Although it probably does exactly that, deleting any text entry resulting from previous font-setting).

I would definitely want to fix each form once rather than leaving it defined incorrectly and adding more code to fix it at runtime. That change will leave you with a worse problem if you later decide to do something different.