The .NET framework is in my opinion an impressive piece of work with many useful classes. But I think every developer has at least once faced the problem that a class or function doesn't exactly fit his needs. Normally, one would derive from it and extend the functionality. The
SaveFileDialog are sealed and thus there is no direct way of extending them. This article explains how you can extend them anyway without the need to make everything yourself.
Once upon a time, in a country far far away...
... a customer had the request that in an
OpenFileDialog - where he could open an image - the default view state of the contained listview should be the thumbnail view. No one in my company really thought about it, and so we just said: "No problem!".
After looking at the given dialog classes, I realized that this wasn't as easy as just setting the appropriate property. I searched the forums and several search engines, but all I could find was listings which showed how to create the dialogs directly via the Windows APIs which needed dozen of
structs with dozen of fields and cryptic constants. This was just too much overhead for me just to change the initial view state. So I began to think about other solutions.
The idea which came to my mind was that the parent form somehow must get to know when and which modal dialog is displayed. So I wrote a form overriding the
WndProc and traced the messages coming while opening a file dialog. After some minutes, I had the message I needed. It has the number 289 and fires in the message loop of the modal dialog. This message also contains the handle to the dialog. It is important that the dialog is fully created at this time, because otherwise the following steps wouldn't work.
Phew! No, I had the handle to the dialog and knew it was shown (I could just have looked at the screen to realize this). Now, I needed a way to change the style of the listview. So I started Spy++ and searched for the dialog (with the handle at hand, this was easy) and quickly found the child window which was containing the listview.
I opened the messages dialog of Spy++ and began changing the listview's view state, and after some filtering, I got the message which was changing the style. The appropriate parameters for the view types were also shown by Spy++.
Now, I just had to add two small API calls to change my dialog. I used
FindWindowEx to search for the handle of the window holding the listview. After retrieving it, I called
SendMessage to send the message delivered by Spy++ to the window.
Using the code
I tried to stuff everything into a component. The problem is that the only one who has access to
WndProc of a
System.Windows.Form is the form itself. Thus, the form that will show the file dialog needs to override
WndProc and make a call to this component. The minimal code to show an extended dialog would be:
public class TestForm : System.Windows.Forms.Form
private System.Windows.Forms.Button _btnOpen;
private FileDialogExtender _extender =
new System.Drawing.Point(8, 8);
this._btnOpen.Name = "_btnOpen";
new System.Drawing.Size(96, 23);
this._btnOpen.Text = "Open";
this.MaximizeBox = false;
this.MinimizeBox = false;
this.Name = "TestForm";
this.Text = "Test";
static void Main()
private void ShowOpenDialog(object sender,
protected override void WndProc(ref Message m)
A better sample project is included in one of the download links.
Points of Interest
I hope I could show you how you can extend system dialogs by finding the needed handles to remote control their behavior.
There is much more one could do this way without throwing away the benefits of using the managed dialog classes. As I have no further need for extensions, I will now leave it at this stage.
If anyone has an idea on how to achieve this functionality without overriding
WndProc or adding other API calls or hooks, please let me know.
- 2004-12-04 - Initial release.