UI Text
Setting the font on a dialog
Managed dialog fonts must reflect the current dialog font setting. Dialogs must be able to set the fonts of certain controls to variations (bold, italic, etc.) of the current dialog font.
To establish your font, set the font property of all controls and the form to be retrieved from the .resx file. In the .resx file, the font properties value should be ResXNullRef.
An example of this in code is:
this.button1.Font = ((System.Drawing.Font)(resources.GetObject("button1.Font")));
And the corresponding entry in the .resx file should be:
<data name="button1.Font" type="System.Resources.ResXNullRef, System.Windows.Forms">
<value />
</data>
Setting the font property of all controls allows the form’s font to be acquired from the Visual Studio Dialog font setting; in addition, all controls on the form get the font property of its container.
The reason that these values are not explicitly set to null in code (or not set at all) is to allow a back door; if a last-minute font bug is found on a particular platform, the .resx file for that platform can be edited and a font can be hard-coded there.
Ensure that the dialog picks up the correct font
For Windows Presentation Foundation (WPF), derive your window class from the shell’s DialogWindow class instead of WPF’s Window class.
In XAML the code looks like this:
<ui:DialogWindow
x:Class="MyNameSpace.MyWindow"
xmlns=https://schemas.microsoft.com/winfx/2006/xaml/presentation
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:ui="clr-namespace:Microsoft.VisualStudio.PlatformUI;assembly=Microsoft.VisualStudio.Shell.11.0"
ShowInTaskbar=“False”
WindowStartupLocation="CenterOwner"
Title=”My Dialog”>
... Snip ...
</ui:DialogWindow>
Code Behind:
internal partial class WebConfigModificationWindow: DialogWindow
{
}
Call “ShowModal()” on the class over ShowDialog(). ShowModal() sets the correct modal state in the shell.
The code is as follows:
MyWindow window = new MyWindow()
window.ShowModal()
ShowModal returns a bool? (nullable Boolean) with the DialogResult, which can be used if needed.
Fonts in editors and design surfaces
The exception to the rule regarding using the environment font is in areas that allow for user customization of the font attributes; this is most often seen in editors and designers. Examine usage scenarios to determine whether user customization is appropriate for the given area.
The following table lists different mechanisms for determining font values and an example of each.
Mechanism |
Example |
Usage |
Fonts and Colors section in the Tools/Options dialog |
Visual Studio Code Editor |
Provide a settings group on this page for the specific designer/editor and state the display items which may be customized. |
Tools/Options/Custom |
Consider a Tools/Options page for highly customized interfaces that require more complex means to specify changes. This is useful if it’s necessary to offer a preview or if user-customizable items aren’t easily identified from a simple list. |
|
Document Property (using either Property Pages or Property Browser) |
Windows Presentation Foundation (WPF) |
This method stores the font in the document itself. This allows the user to change it per document. Provide a default font which may be tied to the system but allows the user to override the default. |
Environment Font |
Project Designer |
This editor does not require tuning individual fonts so it’s preferable to allow for customization through the general environment. |
Design model for UI text
Comprehensible text is crucial to effective UI. In software development vital text is written early in the process as the UI is conceived and coded. This text is seen more frequently and by more users than perhaps any other type of technical writing.
Software users tend to read labels first, namely those most relevant to completing the task at hand. Static text is read with less frequency. Plan for users to start their work sessions with a quick scan of the whole window, followed by a reading of the UI in this approximate order:
Interactive controls in the center
Commit buttons
Interactive controls found elsewhere
Main instruction
Supplemental explanations
Window title
Other static text in the main body
Avoid excessing communication and redundancy
UI text should precisely explain to users what they need to do. Review each window and eliminate duplicate words and statements. Don’t explain the obvious. If more information is necessary for certain users or scenarios then provide a link to detailed Help content. Write your text so that every word holds weight and avoid text that discourages reading.
Usage patterns for UI text
Title bar text
Use title bar text to identify a window or the source of a dialog box.
Main instructions
Use the prominent main instructions to explain what to do in the window or in the page. This is sometimes referred to as “Helper Text”.
Supplemental instructions
Use supplemental instructions to provide any additional information that helps the user understand the window or page.
Control labels
Used on or next to controls, this text identifies individual controls and often gives a cue about what values the user should provide.
Supplemental explanations
An elaboration of the control labels, typically used for command links, radio buttons, and check boxes.
Setting styles on certain fonts
Some dialogs require particular text to be bold or a size other than the environment font; just keep in mind that the minimum font size is 9 point (environment font) while the maximum is 11 point (environment font +2). There are also instances in which localizers will modify font styles for different locales, such as removing bolding from text for East Asian languages.
To make the localization of font styles possible, those styles must be within the .resx file. The best way to accomplish this and still have font styles be editable by the Visual Studio form designer is to set the font styles explicitly at design time. Although this creates a full font object and might seem to break the inheritance of parent fonts, only the font style property is used to set the font.
In order to make localization of font styles possible, the styles must be in the .resx file. The solution is to hook the dialog form's FontChanged event. In the font changed event, walk all controls and check if their font is set. If it is set, change it to a new font based on the form's font and the control's previous font style. An example of this in code is:
private void Form1_FontChanged(object sender, System.EventArgs e)
{
SetFontStyles(this.Controls);
}
private void SetFontStyles(Control.ControlCollection controls)
{
foreach(Control c in controls)
{
//If this control has child controls,
// recursively step through its control collection
if (c.Controls != null)
{
SetFontStyles(c.Controls);
}
// See if control's font has changed.
// It's changed if the control's font reference is
// different than the Form's font reference.
if (c.Font != this.Font)
{
c.Font = new Font(this.Font, c.Font.Style);
}
}
}
Using this code guarantees that when the form's font is updated the fonts of controls will update as well. This method should also be called from the form's constructor, because the dialog might fail to get an instance of IUIService and the FontChanged event will never fire. Hooking FontChanged will allow dialogs to dynamically pick up the new font even if already opened.