什么是一个很好的替代WPF WebBrowser控件？ [英] What is a good alternative to the WPF WebBrowser Control?
问题描述
我有我需要的网络内容添加到 MDI 的WPF应用程序。起初，伟大的它看起来像我有内置的框架的框架控制和 web浏览器控制。鉴于这是一个 MDI 程序的时候，并不需要很长时间地发现，这些都不将工作。
I have an MDI WPF app that I need to add web content to. At first, great it looks like I have 2 options built into the framework the Frame control and the WebBrowser control. Given that this is an MDI app it doesn't take long to discover that neither of these will work.
在WPF WebBrowser控件包装了IE浏览器的 web浏览器ActiveX控件它使用Win32图形管线。在空域的问题几乎总结这件事为抱歉，布局不会玩好起来。结果
The WPF WebBrowser control wraps up the IE WebBrowser ActiveX Control which uses the Win32 graphics pipeline. The "Airspace" issue pretty much sums this up as "Sorry, the layouts will not play nice together".
是的，我曾经想过采取这些渲染和映射网络内容的快照鼠标和键盘事件返回给浏览器的控制，但我无法承受的损失，我真的没有时间来写，并对其进行全面测试。
Yes, I have thought about taking snapshots of the web content rendering these and mapping the mouse and keyboard events back to the browser control, but I can't afford the performance penalty and I really don't have time to write and thoroughly test it.
我已经找了第三方控件，但到目前为止，我只找到的克里斯·卡瓦纳的 铬WPF Web浏览器控制。它包装起来 Awesomium 1.5 。总之这些都是非常冷静，他们玩好与WPF布局。但他们不符合我的性能要求。他们是内存消耗非常重，不能与CPU使用率友好无论是。更何况还是相当马车。如果你有兴趣，我会详细说明。
I have looked for third party controls, but so far I have only found Chris Cavanagh's WPF Chromium Web Browser control. Which wraps up Awesomium 1.5. Together these are very cool, they play nice with the WPF layouts. But they do not meet my performance requirements. They are VERY HEAVY on memory consumption and not to friendly with CPU usage either. Not to mention still quite buggy. I'll elaborate if you are interested.
所以，做任何你知道一个稳定的高性能的的 WPF 的网络浏览器控件？
So, do any of you know of a stable performant WPF web browser control?
感谢。
推荐答案
我不认为有许多全托管Web控件。有在 http://www.modeltext.com/html/ 一个不寻常的（我的作者）。
I don't think there are many fully-managed web controls. There's an unusual one at http://www.modeltext.com/html/ (I'm its author).
这一个Windows窗体控件，而不是WPF。该 Windows窗体 - WPF互操作性常见问题表明，这不是一个问题;但是我不知道使用的是Windows窗体控件的领空问题，是否排除
This a Windows Forms control, not WPF. The Windows Forms – WPF Interoperability FAQ suggests that's not a problem; but I don't know whether the "airspace problem" precludes using a Windows Forms control.
在加方：
- 全面管理
- 高性能：低CPU至少（我不知道你的内存要求是什么）
- 可以拥有它的多个实例在应用程序
在消极方面：
- 只有将由主流浏览器所支持的功能的子集（所以，这取决于你想要什么）
- Beta版的品质
编辑：
看起来不错的工作。
感谢您。
对于这个应用程序，我需要一个全功能的浏览器（我必须支持javascript）。
For this application I need a fully functional browser (I must support javascript).
在这种情况下，这不会为你工作：此控件公开.NET（不是JavaScript的）的DOM API;因此，应用程序可以实现安装DOM事件处理程序，这是用C＃编写，而不是在JavaScript。
In that case, this wouldn't work for you: this control exposes .NET (not javascript) DOM APIs; so, applications can implement and install DOM event handlers, which are written in C# instead of in javascript.
是的，托管在控制直到您需要的分层对象WPF应用程序将正常工作。所有WinForms控件都会存在这个问题，由于渲染管线。见上面的链接。你有没有考虑本地WPF端口？
And yes, hosting the control in a WPF app will work fine until you need to layer your objects. All winforms controls will suffer from this problem due to the rendering pipelines. See the link above. Have you considered a native WPF port?
一个WPF端口是可能的，因为它呈现到/通过一个抽象的设备上下文一样的界面，其中我有两个完整的/不同的实现至今：
A WPF port might be possible, because it renders onto/via an abstract device-context-like interface, of which I have two complete/distinct implementations so far:
- 一个使用
System.Windows.Forms的和System.Drawing中 - 另外就是我的自动化测试框架，它实现了谦虚对话对于GUI回归测试
理论上也许我可以实施第三，为WPF，使用 System.Windows。控制和 System.Windows.Media 。
Theoretically perhaps I could implement a third, for WPF, using System.Windows.Controls and System.Windows.Media.
一种随机的，但你可能会发现这个有趣的：的http：/ /blog.spencen.com/2008/01/19/html-to-flowdocument-converter.aspx
Kind of random but you might find this interesting: http://blog.spencen.com/2008/01/19/html-to-flowdocument-converter.aspx
感谢你为我做的发现这很有意思。在WPF的RichTextBox提供了大量的编辑功能。
Thank you for that: I do find that interesting. The WPF RichTextBox provides a lot of functionality for editing.
这篇关于什么是一个很好的替代WPF WebBrowser控件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
