Creating a Client-side Validator for the DropDownList

I like using Guids. Sure, they're a bit long and difficult to decipher in a database but they have their uses. I typically use them as the primary key for database tables. I often have the need to display a list of values from a database table in a DropDownList control on a WebForm. The value of each entry is the Guid while the text value comes from a description field in each record. When the user selects an item from the DropDownList, I retreive the Guid from the SelectedValue property which is typically used to set a field on a business object, thus creating a reference. Typically the first item in the DropDownList reads "--Select One--" or "-- None --", indicating the the user must select a value (this is represented by the value for Guid.Empty). Consequently the field is "required" - a user must select a value from the list. I do this because I don't want to presume a default value (such as the first item).

The problem them becomes how to validate the DropDownList on the client side such that if the user does not select an item other than the default "--Select One--" item a message is display.

I found a post that shows how to use the CustomValidator control to validate a DropDownList. The problem with this solution is that it does not take into account when a control is embedded within other controls that are tagged with the INamingContainer interface. This interface tells ASP.NET to automatically generate unique "id" attribute values on the ensuing HTML tags generated for a control. This unique id is prepended with the id of each parent control up to the root control. For example, a DropDownList embedded in a Panel control might have the id "ctl00$ddlMyDropDown". Therefore, in the solution mentioned above, we can't simply us "document.getElementById" Javascript function to locate the DropDownList control.

A better solution is to utilize the ControlToValidate property of the CustomValidator control. When this is set at design-time ASP.NET will generate Javascript code to add this value as an attribute of the validator control in the HTML DOM. For instance, looking at the source of the page I'm working on the following code is generated:

var ctl00_MainContent_CustomValidator1 = document.all ? document.all["ctl00_MainContent_CustomValidator1"] : document.getElementById("ctl00_MainContent_CustomValidator1");
ctl00_MainContent_CustomValidator1.controltovalidate = "ctl00_MainContent_ddlFeedbackType";

The property "controltovalidate" contains the fully-qualified unique id of the target control we're validating. We can use the "controltovalidate" property in our Javascript function that is used to validate the DropDownList:

function ValidateFeedbackType(source, arguments)
{
var ddl = document.getElementById(source.controltovalidate);
if (null != ddl)
{
var value = ddl[ddl.selectedIndex].value;
arguments.IsValid = (value != "00000000-0000-0000-0000-00000000000");
}
else
{
arguments.IsValid = false;
}
}

Creating a Simple ASP.NET "Click Once" Submit Button

I often run into a situation where a user tries to click a Submit button more than once on a page when processing takes more than a few seconds. To remedy this, I created a very simple control based on the standard ASP.NET Button control (System.Web.UI.WebControls.Button). I created a new WebControl and inherit from System.Web.UI.WebControls.Button to retain all of the aspects of a standard button. Next, I override the AddAttributesToRender method and include the following code:

protected override void AddAttributesToRender(HtmlTextWriter writer)
{
base.AddAttributesToRender(writer);
writer.AddAttribute("onclick", "this.disabled=true;"
+ this.Page.ClientScript.GetPostBackEventReference(this, ""));
}

The first line calls the base classes implementation and then the second line adds a client-side event handler for the "onclick" event of the button. When the button is clicked, it is disabled and then a postback is initiated. This is important because if you just try to disabled the button, it will not be part of the postback and its server-side processing will not fire. That's why you need to include the postback callback function for the button that can be obtained from the call to ClientScript.GetPostBackEventReference.

User-based Config Files

Here's another useful tip that was prompted after reading this post regarding location-specific config files. In a multi-developer environment it is sometimes necessary to have developer-specific parameters in your config files while maintaining the base configuration file, specifically when using source control. For example, developers may need different connection strings to access different databases during development and testing. In our case the base config file (app.config or web.config) contain a single connection string that is used by the DAL. Therefore, two different developers cannot have separate connection strings in the base config file.

To solve this problem we used the "file" attribute of the section of the config file to specify a user-specific set of configuration parameters. An example of the base config file:

The user.config file contains:

The contents of the section will be merged with the section of the base config file with the settings from user.config superceding those in the app/web.config. Any additional settings in the base config file are preserved, allowing us to have static config parameters in the base config file and only user-defineable parameters in the user config files. Finally, we set the user.config files to be excluded from source control.

Internal Connection Error Masks Root Cause

I though I'd post this in case someone else ran into the same problem.

I'm using VS.NET 2003, SQL Server 2000.

In my case, the error "internal connection fatal error" was being generated when using a DataReader to read the field values of a record. As I stepped through the code in the debugger I was also getting an "arithmetic overflow" error when calling GetDouble on a field. As I looked further it turns out this field in the database table for the given record had the value "-1.#IND". I'm not sure how that value got there but once I delete the record the error went away. So essentially the "internal connection fatal errror" exception was masking the root cause.

Error Creating ASP.NET Application

I was tring to create an ASP.NET website using Visual Studio.NET 2003 and got the following error that in part says:

"Unable to create web project ... The two need to map to the same server location".

I found so many threads about this with few answers. Here's how I solved my problem.

I was trying to create an ASP.NET website on one of my servers from Visual Studio.NET 2003 on my development machine. The problem was that the directory location of the "Default Web Site" node in IIS on the server did not map to the location where I was trying to create the new application based on the UNC path. For example, I was trying to create the application on the following path:

\\myserver\inetpub$\myapplication

This mapped to the physical location:

G:\Inetpub

... and translates to the URL

http://myserver/myapplication

In IIS on the server I looked at the "Default Web Site" node as this is where IIS will try to create the ASP.NET application because http://myserver translates to this location. Looking at the Home Directory tab at the Local Path parameter I noticed it was pointing to the physical location

C:\Inetpub\wwwroot

So, I simply changed this path to G:\Inetpub and it worked. So this is what the message means by "the two need to map to the same server location".

Don't forget of course that I had to create a UNC share with the appropriate permissions for this to work.

Hope this saves someone some time.