关于 WPF 停靠库的建议答案

【问题标题】：Recommendations on a WPF Docking Library关于 WPF 停靠库的建议
【发布时间】：2008-12-05 15:38:36
【问题描述】：

我们正在实现一个需要可停靠窗口的应用程序，类似于 Visual Studio 2005/2008，但与 VS 的单一站点不同，它具有多个“停靠站点”。有没有人为此推荐一个好的图书馆 - OSS或商业？我知道 Infragistics 有一个，还有来自 DevComponents 的 Divelement 的 SandDock 和 WPF-Dock，以及 ActiPro 的 Docking & MDI 产品。 CodeProject 上也有一个。有人用过这些库吗？体验是好是坏？如果您有使用其中之一的经验，它是否支持多个“对接站点”？

【问题讨论】：

作为旁注，如果您对 VS 团队如何在 Visual Studio 2010 中实现对接和各种其他方面感兴趣，blogs.msdn.com/b/visualstudio/archive/2010/03/23/… 上有一组很棒的博客文章
@pat 评论中的 MSDN 链接现已失效。这是来自 Internet 档案的版本：web.archive.org/web/20151025043559/http://blogs.msdn.com/b/…

标签： wpf dockable

【解决方案1】：

来自 Codeproject 的一个是 AvalonDock - 我们使用它已经有半年多了，但我们离发布还很远，所以我们有足够的灵活性。在使用 AvalonDock 之前，我们尝试了 Infragistix、ActiPro、SandDock 以及其他一些。尽管 AvalonDock 不是 100% 没有错误的（那是什么？）没有主要错误，但它非常稳定、快速并且具有所有功能。它确实支持多个对接站点。

它是一个开源项目，正在积极开发中，因此正在发现并修复错误。到目前为止的良好体验。

【讨论】：

AvalonDock（以及所有其他停靠管理器）没有的一个特性是容器中的功能齐全的 ItemsSource 属性。 IE。我真的很希望能够在我的班级中有一个可观察的集合，我可以绑定到 DocumentPane 或 DockablePane 的 ItemsSource 属性，只要我有正确的 DataTemplates，这些将显示为文档或可停靠选项卡/窗口。 ItemsSource 属性在那里，但它的可用性非常有限 - 它只能包含 DocumentContent 或 DockableContent 对象，并且在使用 ItemsSource 时拖放不起作用。
在我发布上述评论后仅几周，该功能就被添加到 AvalonDoc！现在有可以绑定到文档集合的 DocumentsSource 属性。它就像一种魅力。
不存在对 AvalonDock 中绑定的真正支持。只要你给它一个 DocumentContent/DockableContent 的集合，ItemsSource 就可以工作，但我发现耦合和/或额外的工作会导致头脑麻木，至少在我正在从事的项目中是这样。我试图破解一个支持 MVVM 的 AvalonDock 修复程序（当然，有些功能很难转换，比如取消停靠窗口），但由于各种原因失败了，有时当我 this 接近一个可行的解决方案。我发现当前状态下的 AvalonDock 禁止使用最佳实践，并不真正推荐它。
几个月前我刚开始使用 WPF，我需要一个对接功能，并在这里推荐了 AvalonDock。我喜欢开源库的一件事是我有时可以调整源代码以满足我的特殊需要。但是，到目前为止，我对 AvalonDock 的体验非常糟糕。在很多情况下它会崩溃。作者（和社区）没有回应这些问题。我不确定它是否仍处于活动状态，因为自今年 7 月以来没有更新。
我有点担心这个库在过去 2 年中缺乏持续发展。

【解决方案2】：

我已经使用 ActiPro 库几个月了，效果很好。它确实支持多个对接站点。支持非常出色，您可以获得 WPF 中缺少的一些其他控件（日期选择器等）。对我来说，150 美元的钱花得很值。它开箱即用，不用大惊小怪。

我们曾经使用 Divelements 进行 WinForm 控件，但我们认为 Actipro 有更好的支持，所以我们切换到 WPF。

只要我的两分钱。

【讨论】：

我不能推荐 ActiPro 的 Dock - 它是一个出色的对接解决方案（我们将它与 Prism 应用程序一起使用）。我通常讨厌 3rd 方控件，但是这组控件感觉像是来自微软。对象 API 是合乎逻辑的，但也是完整的。我们还使用了 ActiPro Ribbon，这也是一个很好的控制。强烈推荐！
同意。鉴于价格，控制和支持的质量是无与伦比的。我还选择了 Actipro 库，因为与某些其他软件包相比，它的库数量较少。
那么我将成为反对 ActiPro 的声音，dock 的序列化还没有完成，真的很遗憾你不能反序列化停靠在文档窗格中的工具栏。（编辑：对不起，比尔的回答不值得-1）。
@Brad：您说“我不能推荐 ActiPro...”，但您的内容似乎是“我确实推荐...”。你能纠正一下错字吗？
@miliu，Brads 的短语是“我不能推荐 ActiPro 的 Dock”，意思是他真的推荐该产品，这与“我无法告诉你我有多爱.. 。”

【解决方案3】：

不要忘记 GitHub 上的 AvalonDock（WPF 工具包的一部分）。我在其他地方看到过。

最初我打算使用 ActiPro 库（主要是因为我已经在使用他们的功能区），但我可能会给 AvalonDock 一个机会，因为它是开源的。

有人对 AvalonDock 有任何反馈/cmets 吗？

【讨论】：

除了this issue 之外，对我来说在各个方面都非常棒。
或本期：stackoverflow.com/questions/20036898/….

【解决方案4】：

我使用 DotNetBar，因为它有功能区/停靠栏和更多控件，而且价格便宜。太好了。

http://www.devcomponents.com/dotnetbar-wpf/

【讨论】：

【解决方案5】：

SandDock 没问题。我们将它用于项目的 POC 阶段。我在他们的布局保存机制中发现了一些非常糟糕的错误。它生成了 XML，但随后无法加载该 XML；它抛出了一个异常！实际上，我通读了所有生成的 XML，并且在每次生成 XML 之后都必须编写代码来稍微修改它。这似乎不是一个经过深思熟虑的设计。我希望有常见的 WPF 基本类型，比如

Infragistics 稍微好一点，但有问题。事实上，如果您尝试在只有 .Net 3.0 而没有 .Net 3.5 的机器上运行它，它就无法正常工作。 Infragistics 有一个突出的开发问题，我不知道他们是否在解决此问题上取得了任何进展。在浮动窗口并拖动它时，我也有几次崩溃（怀疑这与上面的 .Net 3.0/3.5 问题有关）。我发现这个控件的样式非常不直观。

【讨论】：

【解决方案6】：

我尝试了此处列出的所有库，但它们在某种程度上都有问题。虽然它们很贵，但我会推荐 Telerik 和 Infragistics。 Nevron 值得一提，因为他们的库是我见过的最好的库，但它适用于 WinForms。

【讨论】：

我也绝对推荐 Telerik。当您有技术支持问题时，他们会非常迅速地回复您。
我也推荐 Telerik vs Devexpress 进行控制。他们的控件似乎设计得更好，可扩展性更好。使用 Devexpress，我最初对快速回答感到很高兴，但由于代码的不透明黑盒性质，他们从未停止过需要问题。 Telerik 让我觉得我在学习他们的东西是如何工作的，并且在学习如何扩展东西，最终只会问关于错误或缺失功能的问题，而不是经常需要问关于使用的问题。

【解决方案7】：

一年后... AvalonDock 现在稳定且健壮。还有一个“AvalonDock 包装器”可以简化使用它而不降低它的可能性。见http://sofawpf.codeplex.com/

【讨论】：

sofawpf 链接不见了？
你是如何决定“它是稳定的”的？您是否从数以千计的开发人员那里获得了 3-5 年的统计数据？当然不是。

【解决方案8】：

这是另一个：

http://www.essentialobjects.com/Products/EOWpf/DockView.aspx

这个有许多可以动态切换的内置皮肤。它还有许多可以独立使用的单独控件（例如“Splitter”控件）。

【讨论】：

这个还赠送免费的license key。