I've just fixed a strange bug I was having when comparing a web page in IE and Firefox. The page simply had a single textbox, and a button. By default, in accordance with W3C standards, both browsers will post-back to the server when the user hits <Enter> from within the textbox.

Just the behaviour I wanted, except that when the post-back occurs from IE, the button's event handler does not get triggered on the server!! Very strange ... but this article on 4guysfromrolla.com gives a great explanation.

Basically, IE does not post-back a fully serialised form if there is only one textbox on the page! The server does not know what triggered the post-back and so cannot call the correct server-side event handler. The workaround? ... add another textbox to the form (but just make it hidden!).

This is true for IE6 and IE7 ...

I wanted an animated give for an AJAX application I am working on and was struggling to find anything until I stumbled upon http://www.ajaxload.info. Very simple site (work in progress?) but it gave just enough options to create just the "Wait Image" I needed.

When using the GridView, you can specify an “EmptyDataTemplate” to display when there is no data specified in the DataSource. This is great, but the problem from my point of view is that the column headers are not displayed. I would like them to be displayed, even if there is no data.

In my search for the solution I found the following article which explains how to achieve this result by overriding CreateChildControls:

http://www.dotnetslackers.com/GridView/re-27953_Displaying_GridView_When_No_Data_Exists.aspx

To support Web Farms (multiple machines) or Web Gardens (multiple processors), changes to the ASP.NET configuration will need to be made. Thankfully this is just configuration; no code changes would need to be made.

The main thing to be aware of when setting up for a farm/garden is that a user's request can hit any processor or server. As such, the user's session needs to be available across the entire farm/garden and so session state cannot be held locally in memory, which is the default configuration.

The following links give further details on what can be involved:

Session-State modes: http://msdn2.microsoft.com/en-us/library/ms178586.aspx
Web Garden Model: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/dngrfTheASPNETHTTPRuntime.asp

It's not an error message that you see often when working with ASP.NET, but if you’re deploying to a new, clean machine, it can happen quite easily.

The problem comes around due to the order that components were installed on the machine, namely that The .NET Framework was installed before IIS. As a result, ASP.NET is not correctly configured to run. The easiest way to rectify this is to re-install ASP.NET with IIS.

aspnet_regiis –i

If you only require default settings then this is the easiest option. The Microsoft KB specified in the error message suggests the –ga switch, but that requires a little more knowledge of the Windows system as it requires you to specify the Windows User Account to run under (which is different between Windows 2000, XP, 2003, etc). Easier to simply use the –i switch!

The answer is that in ASP.NET, static variables should be used instead of the Application object. It's something that I had never considered in terms of best practice, until I was asked this week. After a little digging on MSDN I came across the guidelines which state:

• Use static properties instead of the Application object to store application state.
• Use application state to share static, read-only data.
• Do not store STA COM objects in application state.

It comes down to the fact that the Application object is included for compatibility with classic ASP which had no application runtime like .NET.

You learn something new every day! More info can be found in the Knowledge Base article 312607.

This is something I always forget how to do. When you use the Response stream to output a file or image, you often want the name of the stream to make sense. That way, if the user tries to save the file or image, the suggested name is what you specified.

Before ending the Response stream, add something like the following:

context.Response.AddHeader("Content-Disposition", "inline;filename="+ _filename +".png");

A problem I had recently was that a GridView bound to a SqlDataSource was not deleting the records when the Delete command was executed. I've tagged this entry as a "gotcha" as it isn't completely obvious where the problem might be to the uninitiated.

The Delete Sql command was executing fine, but after using SqlProfiler I noticed that the “ID” parameter was set to “Null”, hence the fact that no record was deleted. This was not what I expected as I had used the normal SqlDataSource and DataGrid wizard to set up the controls. What I was missing was setting the “DataKeyNames” property on the GridView to the name of the primary key of my data … “ID”. Now, the SqlDataSource passed through the correct Sql statement and all was good!

I’ve avoided the SqlDataSource/Designer approach whenever possible for the very reason that it’s difficult to see what’s going on when something doesn’t work. I was creating a prototype so time pressures won out and I used it!

It's taken a while, but I finally found a blogging system that I liked.

ThinkJot is an ASP.NET 2.0 version of the latest release of the dasBlog engine. The reason for the split is that when running under ASP.NET 2.0, your site is running by default under "Medium Trust" rather than "Full Trust", which was the case in .NET 1.1. If you're running on a shared host as I am here, you'll probably find that it is running under the default security settings. No problem you think ... well, try running dasBlog 1.8 under "Medium Trust" and you'll find it doesn't work! It turns out that even things such as the date picker used, did some things that needed to run under Full Trust. For the full story go to the blog.

That's where ThinkJot comes in. It was simply a rebuild and tweak to make it ASP.NET 2.0 and Medium Trust friendly. I pass my thanks on now to the guys at Process64 who did this, you saved me a job!