Extending the save file dialog class in .NET / Windows Forms / C#

• Download source files - 4 Kb

Introduction

Sometimes programming is like doing a jigsaw puzzle with a missing corner.

I work at Red Gate Software, the company that produces SQL Compare, which is written in C#. Although C# and the .NET framework enable us to write good code quickly, the combination has its drawbacks. More often than not I find that even though .NET covers 95 percent of the native Windows API, the five percent that’s missing is the five percent I need. This article describes one of these situations.

C# is very good at handling international character support. This means that SQL Compare can handle databases that use diverse character sets. The problem comes when we need to get the T-SQL scripts out of SQL Compare and into other third-party tools.

Tangled web of encoding

There are a number of different ways of saving Unicode data to disk. ASCII encoding doesn’t handle international characters at all – it will only cope with seven-bit values from 0 to 127. UTF-8 encoding is the same as ANSI encoding for seven-bit characters such as A, B, C and D. Other, more exotic, characters are stored as two-, three- or four-byte combinations. Unicode, or UTF-16, encoding normally stores each character as two bytes, although it can occasionally use four bytes. In addition, each encoding type allows a preamble. This consists of two (for UTF-16) or three (UTF-8) bytes written at the start of a file to indicate the encoding of the file.

Not all tools support all encodings. SQL Query Analyzer, for example, supports UTF-16, but not UTF-8 encoded files; if you ask it to open a UTF-8 file it will treat it as ASCII and treat a two-byte international character as two separate characters. If, however, you save files as UTF-16, then editors that are not Unicode-aware will display each two-byte character as two single characters, l i k e t h i s.

Simple solution?

The lack of universal support means that we need to let our users choose the type of encoding they want when saving files to disk. This is where the tricky part starts. .NET provides a SaveFileDialog class that you can normally use to get a filename. Unfortunately, this dialog does not provide a way of asking the user for an encoding. I thought adding this functionality would be a simple matter of inheriting from the SaveFileDialog class and then adding a couple of controls to the dialog. This class is not, however, a simple Windows form. Instead, it uses the Windows GetSaveFileName function to display the save file dialog.

This made things a bit harder. I looked at the MSDN help for the SaveFileDialog class and noticed that there is a protected HookProc method. This lets you hook into the dialog creation process. You should be able to inherit from the class, intercept the appropriate windows messages, and then add the controls onto the form. Unfortunately, the SaveFileDialog class is sealed. This means that you cannot inherit from the class and override the HookProc method.

At this point I did a search through MSDN and the newsgroups. I found a couple of interesting articles by Dino Esposito and some newsgroup postings by Nicholas Paladino that suggested a good approach.

I decided to use the GetSaveFileName from the Windows API. This takes an OPENFILENAME struct. One of the fields of this struct is a hook that expects a function pointer. One of the neat things about .NET interop is the way you can use a managed C# delegate in place of an unmanaged C++ function pointer:

.
.
private delegate int OFNHookProcDelegate(int hdlg, int msg, 
                                         int wParam, int lParam);
.
.
ofn.lpfnHook = new OFNHookProcDelegate(HookProc);
.
.
GetSaveFileName(ref ofn)
.
.
private int HookProc(int hdlg, int msg, int wParam, int lParam)
{
      //function body
}
.
.

When GetSaveFileName is called, the HookProc receives notification messages from the save file dialog box.

I needed to hook into the WM_INITDIALOG message. In the hook I found the location of the standard Save as type: label and combobox and added a new label and combo box for the encoding choices using CreateWindowEx:

int fileTypeWindow=GetDlgItem(parent, 0x441);
RECT aboveRect = new RECT();
GetWindowRect(fileTypeWindow, ref aboveRect);

POINT point=new POINT();
point.X=aboveRect.Left;
point.Y=aboveRect.Bottom;
ScreenToClient(parent, ref point);

int labelHandle=CreateWindowEx(0, "STATIC", "mylabel", 
                               WS_VISIBLE | WS_CHILD | WS_TABSTOP, 
                               point.X, point.Y + 12, 200, 100, parent, 
                               0, 0, 0);
SetWindowText(labelHandle, "&Encoding:");

In addition to intercepting the WM_INITDIALOG message, I needed to intercept the WM_DESTROY and WM_NOTIFY messages to destroy the label and combo box, and to intercept the selection of a file to work out the chosen encoding.

The final dialog box looks like this:

Download the source code

You can download the complete source code for this sample by following the link at the top of this article. Although the sample doesn’t provide all the functionality of the SaveFileDialog class, it should provide a good starting point for you to implement the functionality you need.