Protected members in sealed classes?

Friday 29 April 2005

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.

tagged: » 3 reactions

Comments

[gravatar]
Nathan Moore 3:16 PM on 30 Apr 2005

You have to extend the FileDialog class to make your insert dialog. Which means that any of the convience methods of OpenFileDialog will be unavailable for you to use.

[gravatar]
Kudla 5:16 PM on 30 Apr 2005

See this is where we have crossed the line in today's methodology. It is so convenient to have an OpenFileDialog class, so we don't have to do all that .dlg and MessageProc crapola we used to have to do.

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!

[gravatar]
Ishmaeel 3:51 PM on 27 Aug 2008

Oh, BTW, FileDialog cannot be extended either.

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:

name
email
Ignore this:
not displayed and no spam.
Leave this empty:
www
not searched.
 
Name and either email or www are required.
Don't put anything here:
Leave this empty:
URLs auto-link and some tags are allowed: <a><b><i><p><br><pre>.