HyperlinkField doesn’t work in GridView control

In my previous project, I had to display e-mail addresses for each row in the GridView as a hyperlink to enable users to click on the link which will take them to compose e-mail in OutLook. I was taken aback to see that after the page was rendered, the link didn’t show but the e-mail address was shown as a static text. Bummer!!! I did some research on why ASP.NET 2.0 was behaving like that and found out that the src/href elements were disabled because the data might be malicious. But after few hours of trying, I found a workaround: Instead of using Hyperlink field, we can use a BoundField and set the DataFormatString property.

<a href=mailto:{0}>{0}</a> and this works perfectly. Here {0} is your datafield column from your datasource which has the e-mail address.

Generics like support in .NET 1.0/1.1

Lot of my peers think that Generics support is cool and is only available in .NET 2.0. But there is a way to simulate strongly typed collections in .NET 1.0/1.1. Traditionally, we all use ArrayList to store objects (classes with public properties). But, unfortunately, ArrayList is a weak type and supports any object. So, we lose all the type safety that is available in Generics. Instead of using ArrayList, we can derive our classes from CollectionBase or ReadOnlyCollectionBase abstract classes. This class is strongly typed and provides type safety at compile time.


public class Employees: CollectionBase
{
public Employees()
{
.......
}

public int Add (Employee emp)
{
return List.Add (emp);
}


public int Remove (Employee emp)
{
return List.Remove (emp);
}
....
}

There is one caveat: Even though from the outside, you get strong reference, internally the IList type is still an object. But, it is still better than using ArrayList which is a weak reference type.

Registering ActiveX component from code

Registering a ActiveX component involves using the regsvr32 tool. But, it would be weird to use it from the middle of your code. There is a workaround solution to this by using the following declare statement:

Public Declare Function .DLLSelfRegister Lib “vb6stkit.dll” (By Val lp.dllName As String) As Integer

But, this involves shipping vb6stkit.dll and its dependencies.
Instead, I believed that there should be a more robust way of solving this issue and I came up with this idea which also won the best code snippet in codeguru.com.

http://www.codeguru.com/vb/controls/vb_activex/article.php/c3479

 This code is still valid in the .NET world.

Generating a unique number for each row

T-SQL developers know that using newId() generates new GUID which is guaranteed to be unique each time the function is used.

The other day, in my work I was in a situtation where I need to generate unique numbers for every row selected or inserted. One way of handling it is to create a temp table (create table #tablename) or a TABLE type with a field of type int with IDENTITY (1,1). This will accomplish what I wanted but I still need to create a unique number in another column for each row. A easy and most elegant way around this is to do this: checksum(newid()). Doing a checksum on a newid() is guaranteed to be unique since newId() is itself unique.

Update: I happen to read that checksum() function is not guaranteed to give unique values. This is the case with SQL Server 2000 and I believe the same case with SQL Server 2005. For more information on checksum() collisions, take a look at this URL: http://blogs.clarience.com/davide/?p=11.

But, in my case when I implemented this solution (one time thing), I didn’t encounter duplicate entries in the column where I was inserting integer values. If I would have encountered duplicate entires, the underlying trigger or the column’s unique constraint setting would have thrown a error.