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.

This is a useful solution if the editor has settings that can easily fit into this standardized presentation.

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.

This is the most flexible solution for individual documents, though it doesn’t allow for global changes. In advanced cases offer both a Tools/Options page for setting global defaults and then provide the properties available on each element to allow for document-specific customization.

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:

  1. Interactive controls in the center

  2. Commit buttons

  3. Interactive controls found elsewhere

  4. Main instruction

  5. Supplemental explanations

  6. Window title

  7. 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.