Two Ways of Handling Events in the DataGrid WebControl

The DataGrid WebControl allows you to use two ways to handle events. The first method is to specify the event handler as a property of the DataGrid on the aspx page itself.

<asp:DataGrid ID="dgTest" OnEditCommand="dgTest_EditCommand">

Or you can define a subroutine on the aspx.vb file with a Handles keyword.

Private Sub dgTest_EditCommand(ByVal source As Object, ByVal e As
  System.Web.UI.WebControls.DataGridCommandEventArgs) Handles dgTest.EditCommand

In most cases, you want to only use one or the other, but what happens if you use both for the same DataGrid? Visual Studio 2008 will certainly allow you to do this. If the same handler is specified in both places, the handler is called as expected, as if it was only wired in one place. I think this situation should be avoided as it can easily cause unintended consequences later, such as if the developer decides to change or delete the handler in one place and forgets to make the same change on the other. If different handlers are wired in both places, the handler(s) defined in the aspx.vb file will be called first, after which the handler specified on the DataGrid control will be called. The other thing to know is that the handler wired in the DataGrid tag must be declared as protected or public.

I prefer to always wire the handlers inside the aspx.vb file only. This way, any changes to the handler, including something as simple as changing the name of the handler, can be done on the vb file without having to change the aspx file. This also allows you to wire multiple handlers for the same event. Lastly, this also has the advantage of allowing you to define the handler as private, which is what VS 2008 uses by default when it generates the handler for you.

Service Unavailable - HTTP Error 503. The service is unavailable.

One day I tried to start to run my application on Visual Studio 2008 and got the following error: Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.






So I clicked on Start Without Debugging as suggested and got the following error: Service Unavailable - HTTP Error 503. The service is unavailable.

 


This usually means that my web server is not running. I did a quick check inside IIS Manager, and found that my web site was running, but the application pool was not. I started my application pool and tried again but got the same error. I refreshed my application pools and found that it was not running again. It turns out that the password of the identity that my application pool was using had changed. I clicked on my application pool, went to Advanced Settings | Process Model | Identity to update the password to fix the problem.

Hidden LoadPostData in Page Life Cycle for Dynamic Controls

One of the most basic things that an ASP.NET programmer must be familiar about is the page life cycle. This is very well documented in several places, but I always refer back to MSDN's beautifully illustrated chart almost halfway through the page here.

While debugging an application that dynamically adds controls to the web page, I found a bug caused by events not firing in the expected sequence. Basically, we used a custom control that assumed that the LoadPostData event data is always fired before the Load event. As I will explain later, this is not always true. I modified the page life cycle diagram, with my addition highlighted with a green background to add a very important event not shown in the original.

Page Life Cycle Diagram Showing Second LoadPostData Event

The problem was originally caused by my application dynamically adding a control during the page load event. What this means is that during the postback's first LoadPostData event, the control has not been added to the control tree yet. This might imply that during postback, controls that are dynamically added during the Load (or later) events will not receive a LoadPostBack event. In reality, a list of all control ID's in the viewstate that was not found during the first LoadPostData is automatically saved. After the load events are completed, ANOTHER round of LoadPostData event, highlighted in green above, is fired using this list. This is somewhat mentioned under the section Catch-Up Events For Added Controls, but is not explained in any useful detail.

Going back to my original problem, the custom control in question would crash when the LoadPostData event is fired after the Load event had already fired. This means that when you're writing your own custom controls, you should not assume that the LoadPostData event is always fired before the Load event. Knowing this, I was able to make changes to fix the bug in the custom control. To follow best practices, I also overrode the CreateChildControls method and moved all code that added controls to the form here. Then I called the EnsureChildControls method during the page load event.

Mysterious Command Line Arguments in Visual Studio 2008

I was debugging a VB.NET program and noticed that the program runs with command-line arguments. This wouldn't be strange if not for the fact that when I open the project properties (right click the project and select properties) and check the Debug tab, the Command line arguments section is empty.

Project Properties with advanced build configuration disabled

After monkeying around for a while, I found that Visual Studio lets you simplify the build options, thereby hiding some options in this tab. To show all the available build options, go to Tools -> Options, select General under Projects and Solutions, and check Show advanced build configurations as shown below.

Tools -> Options Dialog

After enabling advanced build configurations, my debug tab now shows the familiar Configuration drop-down, and the corresponding Command line arguments magically appear!

Project Properties dialog with advanced build configuration enabled

Personally, I would have preferred if the Configuration drop-down is always visible. Most developers would probably be confused by this behavior and would not intuitively know to enable advanced build configuration to find the mysterious command line arguments in this program.