WindowsFormsHost是否适合目的(.net WPF托管WinForms)？

GUI驱动的应用程序需要托管一些基于WinForms的预构建组件。
这些组件使用GDI和DirectX的混合物提供了高性能的交互式视图。
视图处理控件输入并显示自定义图形渲染。
组件由供应商在WinForms工具中进行了测试。

商业应用程序可以将WPF用于其GUI并依靠WindowsFormsHost托管WinForms组件吗？
您是否遇到过技术故障，例如输入滞后，更新问题会让您保持谨慎？

我们当前在软件中使用WindowsFormsHost来托管WinForms DataGridView控件，并且它没有任何实际问题。不过要注意以下几点：

第一个是空域限制。实际上，这意味着WinForms内容总是出现在WPF内容之上。因此，如果您使用的是WPF装饰器，则当它们与您应用程序中的WinForms区域碰撞时，它们将被"修剪"。

第二个原因是，由于它们使用Windows资源，因此您必须更仔细地管理WinForms组件的生存期。与WPF组件不同，WinForms控件需要在完成后才进行处理。这使得将它们包含在纯XAML视图中变得很棘手。

最后一件事是WinForms控件的调整大小似乎不如WPF显示的其余部分平滑：一旦完成调整，它们往往会捕捉到新的大小。

我遇到的一个问题是嵌入式Win Forms控件不参与应用于其WPF容器的任何转换操作。这会导致视觉闪烁效果，并且嵌入式控件会出现在不适当的位置。我通过将Windows Forms Host的可见性绑定到其WPF容器的动画状态来解决此问题，以便隐藏嵌入式控件，直到动画完成为止，如下所示。

您可以使用.net 3.5 SP1解决空域问题：

These types of airspace restrictions
represent a huge limitation in a
framework, like WPF, where element
composition is used to create very
rich user experiences. With a D3DImage
solution, these restrictions are no
longer present!

请参阅D3DImage简介。

正如@Kent Boogaart所述，我遇到了以下情况：WinForms中托管的WPF应用程序没有WPF应用程序对象(即Application.Current)。这可能会导致许多问题，例如分派器无法将线程调用回UI线程。仅当您在WinForms中托管时才适用，反之则不然。

我还遇到了模式对话框的奇怪问题(即ShowModal调用)。我假设这是因为，在WinForms中，每个控件都有其自己的Win32句柄，而在WPF中，整个Window只有一个句柄。

无论做什么，请测试：)

请注意在Winforms中托管时不存在WPF Application对象。如果您要使用现有的WPF组件并将其托管在Winforms中，则可能导致问题，因为资源查找等之类的信息永远不会出现在应用程序范围内。如果有问题，可以创建自己的Application对象。

我在WinForms中托管了WPF控件，反之亦然。但是，我将广泛测试此类情况，因为很难预测复杂的控制方式。