Search

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

Closed
as Won't Fix Help for as Won't Fix

2
0
Sign in
 to vote
Type: Bug
ID: 767103
Opened: 10/11/2012 1:56:45 PM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
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.
Details (expand)

Visual Studio/Team Foundation Server/.NET Framework Tooling Version

.NET Framework 4.0

Steps to reproduce

Attempt to cast the return value of HtmlElement.DomElement to HTMLSpanElementClass using Office 64-bit + WebBrowser control

Product Language

English

Operating System

Windows 7 SP1

Operating System Language

English

Actual results

Returned instance is of type System.__ComObject

Expected results

Returned instance is of type HTMLSpanElementClass (as when Office 32-bit is used)
File Attachments
0 attachments
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(http://support.microsoft.com)
Sign in to post a workaround.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement