Friday 29 April 2005 — This is over 19 years old. Be careful.
Here’s the latest .NET head-scratcher: I wanted to put up an Open File dialog. Simple, use the OpenFileDialog class. Works great. Now I want to change the text of the Open button to “Insert”. In the Win32 world, there’s a hook procedure you can provide that lets you intercept window messages. You can customize the dialog by adding behaviors to specific messages. For example, on WM_INITDIALOG, you can change the text of a button.
Looking at the members of the .NET OpenFileDialog class, I see it has HookProc, described as:
Defines the common dialog box hook procedure that is overridden to add specific functionality to a common dialog box.
Perfect! Except that OpenFileDialog is a sealed class (C# lingo meaning you can’t derive your own classes from it, like Java final). What?! How is this useful to me? D’oh! How do I override behavior in a common dialog?
And another thing: Why show me this member in the docs? Just as the docs don’t describe private members, they should omit protected members in sealed classes.
Comments
The cost is flexibility. Your new colleague, Pete Lyons, bemoans the same fact of .NET life in his blog. Have you met him yet?
Why .NET feels the need to publish sealed classes with virtual protected methods seems a bit absolutist to me (or was that another thread?).
Let's face it, writing a FileDialog class that does what you want is way better than having to do it from scratch. I guess I am saying, quit yer whining and write the code!
It is public abstract, yes, but it has several abstract methods marked internal and since you cannot implement those, extending FileDialog is a no go too.
Add a comment: