Same Old Applications

We run into ASP.NET 2.0 run-time error when trying to export GridView to Excel. 
Simple method we used look like: 

public void GridView2Excel(GridView CurrGridView, string FileName)
{
HttpContext.Current.Response.Clear();
HttpContext.Current.Response.AddHeader("content-disposition", "attachment;filename=" + FileName);
HttpContext.Current.Response.Charset = "";HttpContext.Current.Response.ContentType = "application/vnd.xls";
System.IO.StringWriter stringWriter = new System.IO.StringWriter();
System.Web.UI.HtmlTextWriter htmlWrite = new HtmlTextWriter(stringWriter);

CurrGridView.RenderControl(htmlWriter);

HttpContext.Current.Response.Write(stringWrite.ToString());
HttpContext.Current.Response.End();
}

And the methods throws run-time error saying "...of type 'GridView' must be placed inside a form tag with runat=server". And our GridView was of course inside the form tag with runat=server tag.

It happens that RenderControl throwing error - because of the "wrong timing" in page life cycle it couldn't find the GridView inside Form tag.
The workaround is simple: just override the Page.VerifyRenderingInServerForm method.

With new C# 3.0 feature Extension methods we can extending existing CLR types without sub-classing or recompiling the original class. Those Extension methods would become a next flame trigger but I don't want to argue about "pro and contra". Maybe some other day ;-)

But I found one usefull solution with Extension methods, feature that lot of people trying to find a "hack" for implementing it: the Response.Redirect in a new window.

The "growing" usage of Session and Cache is number one cause of server memory problems. We could call them "server-side" enemy number one. On the other side the user who is waiting for the page with a huge ViewState would soon turn into ex-user. We could call huge ViewState as "client-side" enemy number one. For the quick view and findings of those enemies-numero-uno we can use some simple advices from the blog posts.

For Session and Cache tracing:
Use WinDbg, take a memory dump and look at what your ASP.NET sessions doing in your memory space, spy on ones that take more and more space and do it on production server. Read the Debugging Script: Dumping out ASP.NET Session Contents post and use script provided by Tess Ferrandez. It's simple and usefull. And showing the truth, the whole truth and nothing but the truth.

For track ViewState size:
Using one simple JavaScript method activated from brosers URL field. Look at the script at How Big is Your ViewState?.

My friend Josip points me to the very usefull generate AJAX loader animation web site (still in BETA but works just fine) for generating AJAX „please wait“ animations.
So... if you need a quick icon for your new web 2.0 application just select the shape and colors... and your AJAX indicator animation is ready for download. Try it yourself at http://www.ajaxload.info/!

Let your users share ""please wait" user expirience ;-)

If you try to use ASP.NET AJAX toolkit inside of IFRAME you might get JavaScript error:
"Sys.ArgumentOutOfRangeException Value must be an integer Parameter name: x Actual value was: NaN". Error message says "Value must be an integer" but you had to guess where parameter "x" pointing to :(

ASP.NET AJAX is expecting frameborder attribute of IFRAME tag as Integer (btw. this is corect behaviour, see: HTML 4.0 standard). If you set frameborder value to “yes” or “no” (this is usual formating and browsers would know what to do with it) Sys.ArgumentOutOfRangeException will rise.

Solution is to change this value to „0“ or „1“ and after that ASP.NET AJAX and all controls from its toolkit should work just fine.