Question

We have an ActiveX component that displays a Web page in an Internet Explorer window via SHDocVw. In the DocumentComplete event handler, we attempt to retrieve the value from one of the controls on the page. We know the control is on the page (it’s visible via a Fiddler trace).

It’s at this point that things get wonky. We receive the following error message at runtime:

Error Message:  
  Public member 'elements' on type 'DBNull' not found.
Error Routine Location:  
   at Microsoft.VisualBasic.CompilerServices.Symbols.Container.GetMembers(String& MemberName, Boolean ReportErrors)
   at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
   at Foo.AddinModule.m_internetExplorer_DownloadComplete(Object pDisp, Object& url)
Error Source:  
  Microsoft.VisualBasic
Error Site Location:  
  System.Reflection.MemberInfo[] GetMembers(System.String ByRef, Boolean)

The offending line of code is this one:

Me.IEInstance.Document.forms("frmRedirect").elements("redirectData").Value = outlookXML.OuterXml

So, essentially, Me.IEInstance.Document.forms("frmRedirect") is evaluating to DBNull.

We’ve eliminated case sensitivity issues. Tried moving the control around within the page, and verified that the HTML is well-formed. I have no idea why this is occurring. A sample of the generated HTML is below.

Can anyone suggest a cause and a possible resolution for this issue? I’m entertaining any and all suggestions at this point.

HTML Sample

<form id='frmRedirect' name='frmRedirect' action='pw_outlook/choosecontacts.aspx' method='POST'>
    <input type='hidden' name='redirectData'>
</form>

UPDATE 3/28/2012

We have determined that the code works fine under certain configurations. Then, mysteriously, it will succeed for some users if you change the code as follows:

Me.IEInstance.Document.forms("frmRedirect").Elements("redirectData").Value = outlookXML.OuterXml
                                            ^
                                            ^

That is, if you simply change the case of Elements. This, to me, smacks of a case sensitivity issue during a COM vtable lookup, but the mystery is that it doesn’t occur for everyone. Just some users.

Also, please note that the form that is returned by .forms("frmRedirect") is a valid object; however, it doesn’t appear to have an elements() method.

Answer 1

You are battling a bug in the DLR, the dynamic language runtime that was added in .NET 4. The code on the stack trace is related to the VB.NET binder to the DLR. This bug is almost certainly not triggered by the code you posted, it is likely to be some other code in your project that does something with a dbase query. Given the presence of DBNull in the exception message.

You’ll need support from Microsoft to get to the bottom of this. They’ll need your project to give them a repro to work on, given that the code snippet itself won’t help them find it. You can contact Microsoft Support to get that started. They’ll take a chunk out of your credit card but you’ll almost certainly get it back, given that it is likely to be a bug in their code and not yours.

There is a possible workaround for this particular failure, although it isn’t exactly guaranteed that the DLR corruption isn’t going to cause some kind of problem later. You can write the exact same code without using the DLR by writing early bound code. Start that with Project + Add Reference, Browse tab, select c:\windows\system32\mshtml.tlb

Then rewrite your snippet to look like this:

    Dim doc = DirectCast(Me.IEInstance.ActiveXInstance, mshtml.IHTMLDocument2)
    Dim form = DirectCast(doc.forms("frmRedirect"), mshtml.IHTMLFormElement)
    If form IsNot Nothing Then
        Dim elem = DirectCast(form.elements("redirectData"), mshtml.IHTMLInputElement)
        If elem IsNot Nothing Then
            elem.value = outlookXML.OuterXml
        End If
    End If