John's profileJohn BarshingerPhotosBlogLists Tools Help

Blog


    September 11

    .Net 2.0 performance improvement causes mysterious sinking feeling… and this javascript error: ‘theForm.__EVENTTARGET’ is null or not an object

    Mucking with the DOM may cause this javascript error: ‘theForm.__EVENTTARGET’ is null or not an object

    If you muck with the DOM in javascript as the page loads (I’m not saying you should…) such as:

    document.body.innerHTML=document.body.innerHTML.toString().replace(/\[MultiDayCountText\]/g, strMultiDayCountText);

    What happens is that for events which call the __doPostBack such as <input type=”button” runat=”server”… > the “theForm” variable gets messed up so that the __doPostBack method generates the javascript error: ‘theForm.__EVENTTARGET’ is null or not an object.

    In the asp.net 2.0 version, this is the auto-generated code:

    var theForm = document.forms['Form1'];
    if (!theForm) {
        theForm = document.Form1;
    }
    function __doPostBack(eventTarget, eventArgument) {
        if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
            theForm.__EVENTTARGET.value = eventTarget;
            theForm.__EVENTARGUMENT.value = eventArgument;
            theForm.submit();
        }
    }

    In the 1.1 version, this is the auto-generated code:

    function __doPostBack(eventTarget, eventArgument) {
        var theform;
        if (window.navigator.appName.toLowerCase().indexOf("microsoft") > -1) {
            theform = document.Form1;
        }
        else {
            theform = document.forms["Form1"];
        }
        theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
        theform.__EVENTARGUMENT.value = eventArgument;
        theform.submit();
    }

    You can see that the 2.0 version optimizes things by moving the finding of the form object out of the __doPostBack function. However, since the DOM gets changed by the original problem code, this reference is no longer valid which is what causes the problem.

     There are two things you can do to fix this problem:

    1.  don't muck around with the dom/body html via javascript
    2. don't use __doPostBack, you can simply change the <input type="button" runat="server ...> to <asp:Button ...>

     

    September 08

    Vista RC1 (Build 5600)

     
    yup, I decided to try it even after all my terrible experiences with Beta 2. Guess what? It's not bad. I installed the 32bit version and it had drivers for all the strange components on my motherboard such as HDAD audio, nvidia networking, nvidia SATA RAID, and nvidia display adapter. Yup, it all just worked -- amazing --
     
    Now back to 32bit, I was led astray by the 32bit (x86) version of Beta 2 because it showed all 4GB of RAM that I had installed. What I did not realize that this was another Beta 2 bug (showing 4GB of RAM). With RC1, I only see around 3GB of RAM, since as expected, the display adapter and bios is using the rest of the address space for other things. With the 64bit version (x64), it all shows up. Oh well, I guess at some point I will re-install the x64 version and use it instead. For now, life is "pretty" good with RC1.
     
    Cool thing I have found: using RDP to connect to another computer will now go above 1600x1200 resolution. So if you have the Dell 24" monitor, you can RDP to another box and see it in all 1920x1200 of its glory. They really should patch all the old systems to fix the 1600x1200 limitation...
     
    Bad things:
     
    UAC is still a pain - I have it on for now, but I might turn if off soon.
    SMTP - where did this go? There is no SMTP server in Vista.
     
    Overall, a MASSIVE improvement from Beta 2. This is the build that should have been Beta 2, I am sure they turned off a lot of people with that release (I was one of them but I am more easy to please than most).