Jesse Ezell Blog

“Future versions of the .NET framework will provide a manifest-based application installer and servicing framework with native Internet support, which provides full application lifecycle management, spanning initial discovery, download, caching, verification, servicing and application hosting in a secure environment. This technology leverages the .NET framework to provide next-generation “Smart Client” application lifecycle management.”[1]

So, how 'bout them pop-up blockers? Recently, one of the projects I am working on ran into an interesting problem. Pop-up blockers were blocking our dialog boxes. These were perfectly valid, user initiated dialogs. The problem, however, is that the google toolbar (and others) seems to think that if you post back before popping up a dialog, then the dialog that you pop must be an advertisement. Of course, users tend to be too ignorant to know what is going on, so they keep clicking and clicking and nothing ever happens. So, we had to come up with a solution for this. The two requirements were:

1: It has to be a clean solution (no complex, ugly hacks in our code when we can avoid them)
2: It had to support postbacks

Yes, we technically could have eliminated postbacks in most places, but it would have violated #1 to start off with, since we would be doing a lot of extra client side script generation and would be breaking the ASP.NET model (not to mention that it would be too time consuming now that most of the code has already been written, tested and debugged, and the deadlines are yesterday.

So, here is a simplified example of the solution that I came up with that works great so far. Write something like this and insert into your page with a RegisterClientScriptBlock or RegisterStartupScript call:

//----------------------------
function __openDialog()
{
     return window.open(...); // open dialog window, return handle
}

function __openDialogOrDisplayWarning()
{
    var hWindow = __openDialog();
    if(hWindow == null)
    {
        // window was not opened
        document.body.innerHTML += "<div style='position: absolute;...'>You have a !@$@!$^ popup blocker installed that has prevented this document from launching automatically. To prevent seeing this message in the future, disable your popup blocker, or hold down ctrl while launching the document. <input type='submit' value='Launch' onClick="__openDialog"></div>";
    }
}

window.attachEvent("onload", __openDialogOrDisplayWarning);
//----------------------------

Now, there are a few important points here:

1) only user initiated popups (via js onclick) will be allowed through popup blockers
2) if you do not use a handler and attach to onLoad, then there is a chance that the code will execute before the page is loaded, causing a nasty IE error that redirects to a blank page.
3) it looks nicer if you spend some time on the div and make it look like a IE dialog box or something

Yah, in a perfect world we wouldn't need to do something lame like this, but the world just ain't perfect, is it?

I've seen this thing[1] going around for a while now, and would like to note that it is an insanely dumb idea (IMO). Basically, the idea is that you override the render method of your web form to output the whole page, and then keep sending javascript blocks to the client to update a progress bar (never returning from render). Not only do you end up generating horrendously invalid html, you also tie up your server's resources while this long running request is executing. Assuming it is intensive because

a) it takes a lot of processing power

or

b) there are a lot of people doing something that requires relatively little processing

This can only lead to problems. In any case, I wrote more about this in the comments on one of the first posts that suggested this solution [2]. Bottom line, do it right, don't do it this way.

[1] http://www.myblogroll.com/Articles/progressbar
[2] http://www.ddconsult.com/blogs/illuminati/archives/000089.html

Dave Winer has put together all of Chris Lydon's blogger interviews and made them available in a single downloadable zip. > 200 MB, but add that to the list of media to listen to for the next two weeks.

"My friend Curtis, an old-time Silicon Valley monster C hacker, AIMed me to say that he'd seen the Slashdot article:

For the most part, I really enjoy .NET Rocks. However, as Roy points out, the latest .NET Rocks, the one where Carl and Mark hang out at the bar, is a total bomb (just like the last time Carl and Mark babbled about themselves). I turned it off after I wasted 30 minutes or so of my life that I can never get back... (hell, it was so bad, that I'm not even going to put a link to them in this post).

Looks like Joel finally moved in...

“WASHINGTON -- The federal judge in the Microsoft antitrust trial ordered the software company Monday to pay Massachusetts $967,014.52 in attorney fees, less than half what the state had sought.”