Developed a Custom FontDialog as an alternative to the standard .Net FontDialog. Key advantage of CustomFontDialog is the full control over look and feel as it is open source. Source and binary files are available at sourceforge.

CustomFontDialog avoids ‘This is not a True Type Font’ exception that affects the standard dialog in some cases. Most probably the exception happens when some installed fonts have invalid meta information. This exception cannot be caught using try/catch block because the exception is thrown from the code outside .Net framework. The exact exception message is ‘Only TrueType fonts are supported. This is not a TrueType font.’. CustomFontDialog gets around this problem by loading only True Type fonts. More details about the problem with standard dialog can be found here and here.

Moreover, CustomFontDialog provides easy access to recently used fonts by moving them at the top of the list in ‘Recently Used’ section.

Usage

Following C# code snippet demonstrates how to instantiate and display Custom FontDialog.

CustomFontDialog.FontDialog fontDialog = new CustomFontDialog.FontDialog();

// sets the default font
fontDialog.Font = new Font(FontFamily.GenericSansSerif, 10);

if (fontDialog.ShowDialog() == DialogResult.OK) {
   // Font is selected. Get the selected font using 'fontDialog.Font'
}
else {
   // FontDialog is canceled by the user
   // your code here to handle cancel action
}

For the CustomFontDialog to retain the recently selected fonts at the top of the list, the dialog should be instantiated only once and ShowDialog function should be called on the same object whenever the dialog needs to be displayed.

To programmatically add Fonts to be ‘Recently Used Fonts’ section, call AddFontToRecentList method.

Limitation: As compared to the standard FontDialog, CustomFontDialog doesn’t support changing text color.

Updates

Version 0.2.0 (31-May-2014)

Following fixes and enhancements are included in this version:

1- In Font List, arrow keys can be used to move between ‘Recently Used’ and ‘All Fonts’ sections.
2- When user starts typing in Font List, the focus shifts to the filter Text box automatically.
3- Whenever CustomFontDialog is displayed, the focus is on Font List by default.

It seems that .Net library doesn’t provide any way to scroll contents of ListBox through code. Selecting an item by setting SelectedIndex automatically scrolls the list to bring the item into view but this may not produce the desired effect. In my case, I wanted to programmatically select an item and make it the first visible item in the list. This effect cannot be achieved through changing SelectedIndex.

The way around this problem is to invoke Windows API SendMessage function.

To call a function from an un-managed DLL, we have to declare it along with DLLImport attribute.

[DllImport("user32.dll")]
private static extern IntPtr SendMessage(IntPtr hWnd, uint Msg,
                                         uint wParam, uint lParam);

As the declaration shows, we have supply four arguments.

Following is the SendMessage function call to scroll the list. First, we define the constants WM_VSCROLL and SB_THUMBPOSITION. Then we develop the thrid paramter by combining LOWORD and HIWORD. Finally the function is called.

const uint WM_VSCROLL = 0x0115;
const uint SB_THUMBPOSITION = 4;

uint param = ((uint)(lstFont.SelectedIndex) << 16) |
                          (SB_THUMBPOSITION & 0xffff);

SendMessage(myListBox.Handle, WM_VSCROLL, param, 0);

Pressing of a key is detected and handled in Windows Form using KeyPress, KeyDown or similar events.

this.KeyDown += myForm_KeyDown;

private void myForm_KeyDown(object sender, KeyEventArgs e)
{
   //Your code here
}

But these events does not fire when arrow keys are pressed. One way to get around it is to set KeyPreview as true for your Form. In many cases, this also doesn’t work, for instance, when you have buttons on your Form.

In such cases, ProcessCmdKey can be overridden to detect and handle arrow key events.

protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
       switch(keyData)
       {
           case Keys.Down:
               //Handle down arrow key event
               break;
           case Keys.Up:
               //Handle up arrow key event
               break;
           case Keys.Right:
               //Handle right arrow key event
               break;
           case Keys.Left:
               //Handle left arrow key event
               break;
        }
        return base.ProcessCmdKey(ref msg, keyData);
}

After handling the arrow key event if you do not want the standard arrow key functionality to kick in, return true rather than calling return base.ProcessCmdKey(ref msg, keyData); Standard functionality could be to move focus to the next or previous control.

Returning true from ProcessCmdKey means event has been handled and should not be routed further for processing.