使用ElementHost在Winform应用程序中托管WPF UserControl有什么不利之处？

Question

使用ElementHost在Winform应用程序中托管WPF UserControl有什么不利之处吗？

我问，因为总的来说，我觉得我需要花很多时间创建一个新的WPF应用程序，其基本界面看起来不错。从某种意义上讲，如果我创建一个新的Winforms应用程序并对其进行一些控制，我最终会得到一个基本界面，其外观和行为类似于许多其他应用程序，但看起来并不简单。如果我对WPF应用程序做同样的事情我觉得我没有达到相同的结果，我最终会得到一个白色背景的“普通”应用程序，除非我将角色更改为设计师并花费额外的时间使其看起来确定办法。

然而，有些情况下WPF对我来说是可取的，因为它相对容易创建一个风格化的界面。考虑视频播放器控件;在WPF中，我可以创建看起来非常漂亮和自定义的东西，但比Winforms控件花费的时间和精力要少得多。在这些情况下，我使用WPF是有道理的，因为我最终花费的时间少于覆盖OnPaint的时间： - ）。

我意识到我使用了很多主观用语，但这是我在原始问题背后的推理。

更新

只是为了澄清我的“视频播放器控制”示例。 WPF不仅会给我MediaElement进行播放，而且如果我想说，在视频暂停时叠加播放按钮或者我想要半透明的“播放/暂停/停止/音量”当鼠标进入特定位置时，WPF会显示，WPF比任何Winforms替代方案都要简单得多。

修改

也许我有一个配置选项错误或者其他什么，但是当我查看WPF与Winforms控件时，“描述”部分的消失也令人沮丧。更加令人沮丧的是，在WPF属性表单中按F1并不会带您进入您所在的特定属性/事件。

更新

还有其他人吗？我更关注通过在ElementHost中托管WPF UserControl而引入的性能影响和/或功能限制。到目前为止，它听起来像是运行时的一次性开销，但这就是全部吗？

Answer 1

我看到一些潜在的缺点。

首先，您现在有两种方式显示UI。根据开发人员触摸代码，这可能会从维护的角度出现问题。

其次，WPF确实有与之关联的运行时（用于调度事件，依赖项属性管理等），但这是一次性成本。如果您将其用于少量控件，那么您将按照其使用比例支付相对较高的成本。

我不会说这些是交易破坏者，这完全取决于您的应用和您的团队。