Search

Give .NET Windows Forms the MFC 7 look with the Tahoma font as default by Justin Smith

Closed
as Postponed Help for as Postponed

82
Sign in to vote
1
Sign in to vote
Sign in
to vote
Type: Suggestion
ID: 115408
Opened: 7/1/2004 6:05:54 AM
Access Restriction: Public
Duplicates: 116508
1
Workaround(s)
The one thing that I still don’t understand is why the old (and ugly) MS Sans Serif font is still the default font for buttons, text fields, and all other controls in .NET Windows Forms. That Tahoma font is the standard font in Windows 2k/XP, and it's the standard font in MFC 7 programs, so I don't understand why the Tahoma font isn't the default font for .NET Windows Forms applications. I think it would be great if the Tahoma font was made the default font for .NET Windows Forms applications in future betas/release. It would also be nice if text boxes in .NET got the slight indentation that MFC 7 text boxes have.
Details (expand)
Product Language
English
Version
Visual Studio 2005 Beta 1
Category
Designer
Operating System
Windows XP Professional
Operating System Language
US English
Proposed Solution
Make Tahoma the default font for buttons, text boxes, and all other controls, just like MFC 7 apps have. Also, give the text boxes the slight indentation that MFC 7 text boxes have.
Benefits
Improved Reliability
Improved User Interface
Other Benefits
Improved Reliability
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 7/1/2004 at 12:40 PM
Hi Justin.
Thank you for your suggestion. We will consider this and get back to you with our decision.
Posted by Justin Smith on 7/21/2004 at 4:28 PM
As an update to this suggestion, I’ve created an example program that demonstrates exactly what I am talking about. Now you can clearly see with a side by side comparison how much better MFC 7 style controls look, and how they desperately need to be added to .NET 2.0 Windows Forms for superior visual quality. You can download the demonstration program at http://justin-files.net/MFC7.zip. You need to have the .NET Framework 2.0 installed to run it.
Posted by Microsoft on 8/26/2004 at 2:10 PM
Unfortunately we cannot completely address this issue in the Whidbey timeframe but will do so in a future release. Having said that we are doing the ground work to address this issue. We have a SystemFonts class that will expose DefaultFont (the default font we use today) and DialogFont ("MS Shell Dlg2" which is actually Tahoma 8pt). You should see this in Beta2. In Whidbey we won't be exposing a simple way to set this at design time. You will be able to use this at runtime in a pretty straight-forward manner. In the constructor simply add:

    this.Font = SystemFonts.DialogFont;
    InitializeComponent();

Coupled with the changes we are making to improve our autoscaling behavior this will work well. If you want design time support you can create a base form class that does this and then derive your form's from this base class.

Its worth noting you can do this today using V1.x - something like:

using System;
using System.ComponentModel;
using System.Drawing;
using System.Windows.Forms;
using Microsoft.Win32;

namespace FontForm {
    public class DialogForm : Form {
        public DialogForm() {
            SystemEvents.UserPreferenceChanged
                 += new UserPreferenceChangedEventHandler(SystemEvents_UserPreferenceChanged);
            this.Font = SystemInformation.MenuFont;
        }

        private void SystemEvents_UserPreferenceChanged(object sender,
                                                        UserPreferenceChangedEventArgs e) {
            if (e.Category == UserPreferenceCategory.Window) { //Is this narrowing correct?
                this.Font = SystemInformation.MenuFont;
                this.ApplyAutoScaling();
            }
        }

        protected override void Dispose(bool disposing) {
            if (disposing) {
                SystemEvents.UserPreferenceChanged
                 -= new UserPreferenceChangedEventHandler(SystemEvents_UserPreferenceChanged);
            }
            base.Dispose(disposing);
        }

    }
}

I've included a whole set of notes and background information below that will hopefully help you understand our current font processing and the new dialog font.

mark

Some more background information on this:

GetStockObject
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_1t10.asp

Localization and the Shell Font
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_2np0.asp

MS Shell Dlg and MS Shell Dlg2
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_4qcn.asp

Windows Forms Default Font property
==
Control has a static DefaultFont property that returns the font that Windows Forms applications use.

DefaultFont has the following logic:

    If DefaultFont is not null return

    If on WinNT 4x platform and LCID=JAPAN use "MS UI Gothic", 9pt

    If on Arabic platform use “Tahoma”, 8pt

    Else use GetStockObject(DEFAULT_GUI_FONT)

    If this fails use "Tahoma", 8pt

    Finally fall back to GDI+ FontFamily.GenericSansSerif, 8pt

GetStockObject(DEFAULT_GUI_FONT) returns the logical font “MS Shell Dlg”.

This is then mapped to an actual font – typi
Posted by Justin Smith on 8/29/2004 at 3:58 PM
Thanks Microsoft. It’s good to know you’re working on it for a future release. Perhaps in Visual Studio 2005 Service Pack 1 you can make “MS Shell Dlg2” the default font and accessible within the Visual Studio GUI, as it is the best looking font selection available.
Posted by ljbreedt on 9/29/2007 at 8:45 PM
This is still not fixed in VS 2008 (Beta 2). Come on, how long is it going to take you to fix this simple UI issue?
Posted by opellegrin on 11/21/2008 at 7:57 AM
Also note the "new" suggested font is Segoe UI. Now VS has to decide which font to use.
Posted by Teal Thanatos on 1/5/2010 at 4:04 PM
Microsoft, This issue if completed could have cascade effects such as solving issues like https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=522986 and anything concerning font problems when the font can be quickly easily and smoothly changed program wide with a single change of a sentance.

Please fix this issue.