为什么要在表单上放置标准对话框？答案

【问题标题】：Why put standard dialogs on a form?为什么要在表单上放置标准对话框？
【发布时间】：2011-03-21 19:46:15
【问题描述】：

我在 C#、.Net 2.0 中有一些遗留代码，其中有人将 OpenFileDialog 和 SaveFileDialaog 从工具箱拖到表单上。这会导致打开和保存对话框在创建父对话框时被实例化，并一直保留到父对话框关闭。打开/保存表单实际上只在一个地方使用，每个支持文件在父对话框的生命周期内并不总是打开/保存；这对我来说似乎效率低下。我会做的是：

    using (OpenFileDialog openDlg = new OpenFileDialog() )
    {
        //initialize openDlg...

        if (openDlg.ShowDialog() != DialogResult.OK)
        {
            //handle OK result
        }
    }

这样，当 using 语句超出范围时，OpenFileDialog 将被释放。除非我遗漏了某些东西，否则资源的快速处理（和更快的垃圾收集）的价值超过了不必在需要时实例化打开/保存文件对话框所节省的少量费用。即使每次使用它们的父对话框时都使用打开/保存对话框，我认为始终使用它们并没有什么太大的价值。我的问题是我错过了什么吗？始终保持打开/保存对话框是否有更高的效率？我假设所有其他标准对话框的答案都是相同的：ColorDialog、FolderBrowserDialog 和 FontDialog。

【问题讨论】：

我同意你的“我会做什么”部分。由于 Common Dialogs 需要人工交互，我无法想象性能是一个大问题。如果你有足够多的 Common Dialogs 实例，那么 Memory 是个大问题，我会质疑你在做什么。

标签： c# .net winforms forms

【解决方案1】：

没有必要。这些对话框有一个 Dispose() 方法只是因为它们从 Component 类继承了一个。他们不会覆盖该方法，因为他们实际上没有任何东西要处理。当对话框关闭时，他们使用的所有系统资源都会被释放。 Component.Dispose() 实现也不做任何处理，它只是确保从 IContainer 集合中删除组件。

这是这些对话框包装器的实现细节。其他组件通常确实可以使用 Dispose()，ToolTip 就是一个很好的例子。表单的自动生成的 Dispose 方法确保发生这种情况，请查看表单的 Designer.cs 源代码文件中的“组件”字段。这就是为什么 Component 有一个默认情况下不做任何重要事情的 Dispose 方法。

避免将组件放在表单上还有一个很小的优势，它允许对对话框的 .NET 包装器类进行垃圾收集。但是节省的千字节左右是一个微优化。

从表面上看：如果早期处置这些类对象很重要，微软就不会将它们制成组件。

【讨论】：

【解决方案2】：

我认为“on form”选项应该对新手来说更容易实现，因为工作主要是在编辑器中而不是在代码中。

【讨论】：

【解决方案3】：

好的做法是做你正在做的事情，因为你已经说过这些对话框不需要在内存中停留很长时间，但如果要多次使用它们，最好不要使用它并在应用程序关闭时正确处理它，完全取决于情况。

鉴于这种情况，无论哪种方式听起来你都很好，我不会为此失眠，但无论它是否在它的 dispose 方法中做任何有用的事情，推荐你使用它的方式，这只是一个好习惯。

【讨论】：

【解决方案4】：

优点是您可以根据需要在表单设计器中设置对话框（多选、初始目录、扩展）等。

此外，表单设计器使将 OpenFileDialog 拖到表单上变得非常容易，以至于许多开发人员都这样做了。真的不能怪他们。

这两种方法都没有明显的优势或劣势，我怀疑你会发现任何可察觉的性能差异。

【讨论】：

【解决方案5】：

当我想保留某些设置（例如过滤器）时，我通常会创建表单范围对话框，而不必在我使用对话框的每个地方都设置它们。如果对话框只在一个地方使用，我会使用 using 语句，就像你上面所说的那样。

【讨论】：

【解决方案6】：

我一直想知道这种方法，并且我更喜欢您的 sn-p 中的使用模式。我能想到的唯一可能的原因是，通过将它们制作成组件，可以在设计器中配置它们的属性。

不是一个非常令人信服的理由（恕我直言）。

【讨论】：

【解决方案7】：

我大体上同意。但是如果对话框有很多“默认”属性数据，性能可能会略有提升。考虑一个带有 50 个文件类型过滤器的文件打开对话框。

【讨论】：