Windows Forms FileDialog

In my comments Kevin Westhead asks about the Windows Forms FileDialog.  I was able to speak to grandpuba of Windows Forms, Mark Boulter who explained this as recommend a fix to the documentation:


FileDialog is a detail of the implementation of OpenFileDialog and SaveFileDialog. It exists purely to allow us to share code between these two classes. If we could make this class internal whilst making OFD and SFD public we would have done so.


 The documentation should explain this more clearly. The statement:

 "FileDialog is an abstract class, and cannot be created directly. Additionally, you cannot inherit from this class. To create a dialog box to select or save a file, use OpenFileDialog or SaveFileDialog."

Is close to nonsensical and should be replaced with something like:

"FileDialog is an abstract class that contains common behavior for the OpenFileDialog and SaveFileDialog classes. It is not intended to be used directly but contains common behavior for those two classes. You can neither create an instance of FileDialog nor inherit from it. To create a dialog box to select or save a file, use OpenFileDialog or SaveFileDialog."


Hope that helps

Comments (3)

  1. Ilya Ryzhenkov says:

    Isn’t there too much "not intended", "for internal use", "you cannot" in FCL? Most interesting things and advanced techniques are hidden either in internal methods and classes or under such "help" topics. I would be happy to use ISplitWindowService in designer to group my components, but I can’t. (not only because it’s internal, see And there are PLENTY of such things in Windows Forms, and even in BCL. IMO, having children around that fall from two-wheels bicycle is not enough reason to add 3rd wheel to every bicycle.

    So, what is the reason to NOT allow developers to use FileDialog?

  2. Jerry Pisk says:

    IMHO those two sentences are created automatically for each abstract and can’t-use-as-a-base-class class. You have to treat them that way, don’t think about what they’re saying, think about them as markers for abstract classes, treat them as English equivalent of keywords 🙂 Btw why can’t you inherit from that class? Short of private abstract method there’s nothing to stop you since OpenFileDialog and SaveFileDialog inherit from FileDialog…

  3. Kalon Jelen says:

    I’m curious to know why this couldn’t have been hidden as an implementation detail. Instead of inheriting from a public base class, aggregate the abstract internal class and have a way of accessing whatever interface you want from other classes, and have the Save/Open File dialogs either implement an interface that looks a lot like FileDialog, or inherit from an Impl-type class that knows how to get a FileDialog object.

    What causes this to not occur here?

Skip to main content