Click here to Skip to main content
Click here to Skip to main content

Hacking FontDialog

, 23 Aug 2008
Rate this:
Please Sign up or sign in to vote.
How to hide UI elements of a FontDialog (e.g., Font Size).

Introduction

It is a common problem that we want to use Common Dialogs (like the Font dialog), but we do not want to allow users to select all the properties offered by the dialogs. This article shows how we can do that, with the font dialog as an example.

Background

I definitely needed a font dialog without the font size property, for a drawing application which manages font size automatically, so we do not want users to be able to alter it. There are two options to select from:

  1. Rewriting the whole Font dialog.
  2. Hacking it.

Since it offers a nice Font preview, I decided to take the second approach.

Hacking

If we have the handle of the window to be hacked, the whole problem is very easy. A few native function calls should be added, like:

[DllImport("user32.dll")]
static extern IntPtr GetDlgItem(IntPtr hDlg, int nIDDlgItem);

[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

const int SW_HIDE = 0

Each UI component of a Common Dialog has a fixed ID. Spy++ can help us identify them. In the case of Font Size, these are 1090 and 1138; so, we can hide the unwanted components by calling:

ShowWindow(GetDlgItem(dialogHandle, 1090), SW_HIDE);
ShowWindow(GetDlgItem(dialogHandle, 1138), SW_HIDE);

Finding the dialog handle

The key problem is identifying the dialogHandle. The sample shows three possible solutions, two of which are popular but have their own problems.

  • FindWindow: Let’s find the font dialog after it is shown, using a FindWindow() native call. Before showing the dialog, a timer is started, which finishes if the dialog is found. This approach has the following problems:
    • What is the right interval of the timer? If a large amount of time is selected, users can see the unwanted UI elements which later disappear.
    • FindWindow takes the title of the window as an input parameter. If Windows isn’t English, the title of the Font dialog isn’t "Font".
    • If it cannot find the right dialog, it will continue running till eternity.
  • GetActiveWindow: Let us suppose that the active window is our Font dialog; again, start a timer before showing it, and hope that the font dialog will be the active window when the timer first ticks. Again, the right timer interval is unknown, and if by any chance our Font dialog is not the topmost, we send commands to another application.
  • Best solution: let’s take the approach described in this article: Customizing OpenFileDialog in .NET.

I removed all the unneeded code from it to get a simple solution to our problem. The FontDialogEx class is to be used instead of the FontDialog. Its ShowDialog method creates a dummy, invisible form named DummyForm. Invisibility is achieved by setting a flag named UFLAGSHIDE. DummyForm waits until it gets activated, this is to be found in its overwritten WndProc(ref Message m) function.

protected override void WndProc(ref Message m)
{
  if (mWatchForActivate && m.Msg == (int)Win32.WM_ACTIVATE)
  {
    mWatchForActivate = false;
    mFontDialogHandle = m.LParam;
    mNativeDialog = new FontDialogNative(m.LParam, mFileDialogEx);
  }
  base.WndProc(ref m);
}

This is the place where we can find the handle of the Font dialog. FontDialogNative is created after the right handle is found, so our unneeded UI elements can be hidden in the constructor of FontDialogNative.

History

This is the first version of Font Dialog hacking.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

legcsabi

Hungary Hungary
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 23 Aug 2008
Article Copyright 2008 by legcsabi
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid