Regression: Office 64-bit/WebBrowser ctrl in VSTO add-in, gets different DomElement type - by Shaun Logan

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 767103 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/11/2012 1:56:45 PM
Access Restriction Public


I have an application-level VSTO add-in developed using VS2008 for Excel.  One of the features of the add-in is to display a Winforms Form (modal dialog) containing a .NET WebBrowser control.  The add-in code hooks the DocumentCompleted event for the control, and during the handling of that event we access the page's DOM to get an HtmlElement.

This code:
HtmlElement elem = browser.Document.GetElementById ("mySpecialSpanId");
HTMLSpanElementClass spanElem = elem.DomElement as HTMLSpanElementClass;
spanElem.HTMLElementEvents_Event_onpropertychange += new HTMLElementEvents_onpropertychangeEventHandler 

works fine on Windows 7 64-bit running Office 2010 32-bit. But it fails on Windows 7 64-bit running Office 2010 32-bit.  The failure is that the third line adding the event handler throws because spanElem is null using 64-bit Office, but works fine using 32-bit Office.  Root cause is that using 64-bit Office, the type of spanElem is: System.__ComObject not HTMLSpanElementCLass as it is on 32-bit Office. 
Sign in to post a comment.
Posted by Microsoft on 11/14/2012 at 1:47 PM
Thank you for reporting this issue. Customer feedback is a critical part of a successful, impactful software product. Unfortunately another part is the reality of schedules and the need to prioritize investments according to the objectives of the product. We have evaluated the issue that you have reported and at this point in the product's lifecycle, it does not meet the criteria to be addressed. This evaluation is carefully done and considers many aspects including the cost of the fix, implications of the change, and the number of reported instances of the issue.
It is preferable to access <snap> element by the corresponding interface in order to avoid dependency on the implementation details in MSHTML. Unfortunately it's impossible to configure WebBrowser to load MSHTML out of process.

Thank you,
The Windows Forms Product Team
Posted by Shaun Logan on 11/14/2012 at 12:17 PM
Thanks for the suggestion to change the code. I have already done that in the latest version of the add-in which I will be making available to customers. Is there any workaround (eg. registry setting) that can force the .NET WebBrowser control to run in 32-bit mode even when hosted by Excel 2010 running in 64-bit mode? I have many customers out in the field using the current version of add-in who want to upgrade to Office 2010 but are unwilling or unable to upgrade their add-in at this time. So I am looking for a configuration-based workaround that will avoid the regression until they can upgrade their add-ins. Thanks.
Posted by Microsoft on 11/14/2012 at 12:35 AM
Hi Shaun,

You can use the following code:
IHTMLSpanElement spanElem1 = elem.DomElement as IHTMLSpanElement;
to access the <span> element.

Thank you,
Windows Forms Product Team
Posted by Shaun Logan on 10/12/2012 at 11:25 AM
The quickest way to reproduce this is to create a simple Excel add-in that puts up a WinForms dialog which hosts a WebBrowser control. Then hook the WebBrowser.DocumentCompleted event and put the code from the above comment into the event handler. Load a document into the browser containing a <span> element with a known id.

If you run it on 32bit Office vs. 64bit Office you can see the different behavior.
Posted by Microsoft on 10/11/2012 at 9:09 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/11/2012 at 2:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(