我有一个令人沮丧的问题。这是我正在做的事情的简化版本：
c# 中的 UserControl 包含一个工具栏和一个嵌入的 WebBrowser 对象。工具栏包含一个“编辑”按钮，单击该按钮会将 Web 浏览器控件设置为设计模式。另一个按钮“取消”可关闭设计模式。
伪代码（非常简化）：
public void SetDesignMode(bool dm) {
IHTMLDocument2 doc = webBrowser.Document as IHTMLDocument2;
if (dm) doc.designMode = "On";
else doc.designMode = "Off";
_designMode = dm;
ReloadDocument(); // setting designmode clears the document element, so it must be reloaded
}
public void OnLoadCompleted() {
IHTMLDocument2 doc = webBrowser.Document as IHTMLDocument2;
if (!_documentLoaded) {
if (_designMode) doc.designMode = "On";
else doc.designMode = "Off";
ReloadDocument();
_documentLoaded = true;
}
}
public void ReloadDocument() {
_documentLoaded = false;
// code that navigates to the document
}
问题：
如果我单击显示的网页，然后单击“编辑”按钮，WebBrowser 控件将无法编辑。将鼠标悬停在图片/链接上时，鼠标指针显示网络浏览器导航鼠标指针，而不是编辑鼠标指针。如果我单击文本，插入符号将不会显示。
调试显示，在这种情况下，文档上的 designMode 属性实际上设置为“On”，但控件的行为就像设置为“Off”一样。
如果我不这样做在点击“编辑”按钮之前先点击网页，一切都会按预期进行。
详细说明：
如果我在控件处于设计模式时单击“取消”按钮，如果已单击文档，我会得到相应的（错误）行为。
只需单击“编辑”，然后单击“取消”，然后单击“编辑”等无需单击文档就可以正常工作（鼠标悬停测试显示正确的鼠标指针，如果单击显示文档中的链接，我可以根据设计模式进行链接导航或编辑）。
我尝试了各种技术来确保在更改 designMode 属性之前另一个控件获得焦点，但这没有任何区别。我搜索了MSDN和一半的已知互联网，没有发现任何提及此类问题的信息。像这样翻转 designMode 属性似乎很不寻常。
另一条信息：我通过使用用户控件实现的接收器向文档提供建议来设置文档事件。我怀疑这应该对问题有任何影响，但为了完整起见，我将其包含在这里。 更新：禁用此功能不会改变有关问题的任何内容。
有人认识到这个问题吗？
更新：
我通过在 SetDesignMode() 中重新创建 Web 浏览器控件来解决该问题。这是一个丑陋的解决方案，但它有效并且看起来确实不错。不过，我对有关此问题的任何反馈都很感兴趣。我相信这是 MSHTML 中的一个错误。
I have a frustrating problem. Here's a simplified version of what I'm doing:
A UserControl in c# contains a toolbar and an embedded WebBrowser object. The toolbar contains an "Edit" button, which when clicked sets the webbrowser control in design mode. Another button, "Cancel", turns off design mode.
Pseudocode (very simplified):
public void SetDesignMode(bool dm) {
IHTMLDocument2 doc = webBrowser.Document as IHTMLDocument2;
if (dm) doc.designMode = "On";
else doc.designMode = "Off";
_designMode = dm;
ReloadDocument(); // setting designmode clears the document element, so it must be reloaded
}
public void OnLoadCompleted() {
IHTMLDocument2 doc = webBrowser.Document as IHTMLDocument2;
if (!_documentLoaded) {
if (_designMode) doc.designMode = "On";
else doc.designMode = "Off";
ReloadDocument();
_documentLoaded = true;
}
}
public void ReloadDocument() {
_documentLoaded = false;
// code that navigates to the document
}
The problem:
If I click on the displayed web page, and then on the "Edit" button, the WebBrowser control will not become editable. The mouse pointer when hoovering over pictures/links show the web browser navigation mouse pointers, not the editing ones. If I click in the text, the caret won't display.
Debugging reveals that the designMode property on the document is actually set to "On" in this situation, but the control is behaving as if it is set to "Off".
If I don't click in the web page before clicking the "Edit" button, everything works as expected.
Elaboration:
If I click the "Cancel" button when the control is in design mode, I get the corresponding (mis)behaviour, if the document have been clicked in.
Simply clicking on "Edit", then "Cancel", then "Edit" etc. without ever clicking in the document works fine (the mouseover test shows the proper mouse pointers, and I get link navigation or editing depending on the design mode if I click a link in the displayed document).
I've tried various techniques to make sure that another control gets focus before I change the designMode property, but it doesn't make any difference. I've searched MSDN and half of the known internet and haven't found any mention of this kind of problem. Flipping the designMode property like this seems to be quite unusal.
One more tidbit of information: I'm setting up document events by advising the document with a sink implemented by the usercontrol. I doubt that this should have any bearing on the problem, but I've included it here for the sake of being complete. Update: Disabling this doesn't change anything regarding the problem.
Does anybody recognize this problem?
Update:
I've worked around the problem by re-creating the web browser control in SetDesignMode(). It's an ugly solution, but it works and does actually look ok. I'm very interested in any feedback on this problem, though. I believe it is a bug in MSHTML.
发布评论
评论（2）
我不太确定我们是否遇到完全相同的问题，但我想我的解决方案也应该适合您。
基本问题似乎是 x64 重置了 designMode 属性，如 这篇文章。就我而言，我在实例化网络浏览器后将其设置为“打开”，但在 DocumentCompleted 事件中，它再次“继承”。在 DocumentCompleted 中将其设置回“打开”使其可编辑，但会清除文档。再次设置 DocumentText 会重新启动整个厄运循环。
因此，我发现的一个解决方案是避免设置 DocumentText，而是创建一个空文档，然后设置正文的（此时不再为空）InnerHtml 属性：
显然，这仅在您准备好文本时才有效，并且如果您导航到 URL，则不会。然而，还有另一种对我有用的解决方案，它看起来更简单、更安全。我在 LaughingJohn 的这个答案中找到了它。我想第一行取决于您的应用程序，您直接在 webBrowser1.Document 中拥有 IHTMLDocument。
I'm not quite sure if we had exactly the same problem, but I suppose my solution should work for you as well.
The basic issue seems to be that x64 reset the designMode attribute, as noted in this article. In my case, I set it to "On" after instantiating the webbrowser, but in the DocumentCompleted event, it was "Inherit" again. Setting it back to "On" in DocumentCompleted makes it editable, but clears the document. Setting the DocumentText again restarts the whole doom loop.
So one solution I found was to refrain from setting the DocumentText, instead I created an empty document, then set the body's (which at this point is no longer null) InnerHtml property:
Obviously, this works only if you have the text ready, and not if you're navigating to an URL. However, there is another solution which worked for me, which seems easier and safer. I found it in this answer by LaughingJohn. I guess the first line depends on your application, you had the IHTMLDocument directly in webBrowser1.Document.
在我看来，当您单击
WebBrowser时，它会获得焦点并以某种方式保留它。试试这个：单击WebBrowser，然后按键盘上的 Tab 键（应该将焦点从WebBrowser上移开），然后看到如果你可以点击你的按钮。如果可以，请尝试将处理程序附加到
Button.MouseEnter事件，并在其中调用((Button)sender).Foucs()以编程方式聚焦按钮。It sounds to me like the
WebBrowsergets the focus when you click on it and somehow holds on to it. Try this: click on theWebBrowser, then press the Tab key on the keyboard (which should move the focus off theWebBrowser) and then see if you can click on your buttons.If you can, then try attaching a handler to the
Button.MouseEnterevent and call((Button)sender).Foucs()in it to focus the button programmatically.