For millennia, mankind has looked to the stars and wondered, “How can I create a generic Dictionary in .NET that allows me use case insensitive strings as keys?” Well today that age old question will be answered with this neat trick.
Simply put, all you need to do is add a StringComparer object when constructing a generic Dictionary that uses a string key, and make sure to use on of the IgnoreCase StringComparers that are offered. Below is some sample code to illustrate just how easy this is.
// Create a generic dictionary with a string comparer that ignores case sensitivity.//// This includes the following:// - CurrentCultureIgnoreCase// - InvariantCultureIgnoreCase// - OrdinalIgnoreCaseDictionary<string, string> stringMap =
stringMap.Add("Test Key", "Some value");
// Now try to access or change the corresponding value with the key.// The case of the key string no longer matters.
stringMap["test key"] = "This will work";
stringMap["TEST KEY"] = "And also this";
stringMap["tEsT kEy"] = "And this as well";
stringMap["tEST kEY"] = "And finally this";
// This can be done with any dictionary that uses a string as the keyDictionary<string, int> numberMap =
numberMap.Add("Test Key", 0);
// Same deal here, you can use any case to get or set the values in the map
numberMap["test key"] = 1;
numberMap["TEST KEY"] = 2;
numberMap["tEsT kEy"] = 3;
numberMap["tEST kEY"] = 4;
And that’s all there is to it. I hope you enjoy and find this useful.
Sometimes you need to insert a data to your database. Here is the safer way to insert a row using SQL parameter.
Passing parameters to SQL prevents you build dynamic SQL statement. Building a dynamic SQL statement is a security risk such as SQL injection.
Here is the sample code for insert statement using parameters.
public void InsertRowToDatabaseUsingParams()
//create SQL connection.
using (SqlConnection conn = new SqlConnection(connectionString))
//open sql connection.
string sqlCommand = "Insert into TestTable (column1,column2) Values(@column1,@column2);";using (SqlCommand cmd = new SqlCommand(sqlCommand, conn))
//add column value to parameters of SqlCommand
SqlParameter param = new SqlParameter("@column1", SqlDbType.VarChar, 50);
param =new SqlParameter("@column2", SqlDbType.VarChar, 50);
Recently, I needed to transmute a Web form into Windows form for a client. There was a subtle issue involving parameters to a SQL stored proc; the stored proc returned matches and near matches to the input values. The return values were missing special characters like ampersand (&).
The solution was to import the Microsoft.JScript assembly and call the Microsoft.JScript.GlobalObject.escape() method.
Microsoft technologies move in decades. Every 10 years or so Microsoft introduces a better way to write Windows applications. My programming experience goes back to Win32 APIs and MFC in the 90s and .NET in the 20th. (Yes, I know Java come before .NET and I actually work with that platform for a numbers of years, but let’s just leave Java out of this discussion.) So here we are in 2010, starting a new decade, is there a better way to write Windows apps?
Windows Forms for .NET dominate thick client applications in the last decade and Microsoft has said that they will continue to support Windows Forms for the foreseeable future. However, three technologies/application types that would put Windows Forms to bed are rich internet apps, cloud apps, and phone apps. The main problem with Windows Forms is that you cannot easily adapt those apps across different devices/app types and that is where XAML shines.
Extensible Application Markup Language (XAML) simplifies creating a UI in .NET. Both WPF and Silverlight use XAML, but the biggest promise for XAML is that XAML-based apps can easily be adapted to different devices. Microsoft has indicated that they want to control 3 screens: PC, TV and phone. Whether or not they will succeed that vision is another story, but I believe that XAML will be the delivery mechanism for these next generation apps.
I don’t see Win32, MFC and Windows Forms for .NET apps going away anytime soon. In fact, I don’t see them going away at all because that’s what Windows is built on. That said, XAML is the better way to write Windows apps for this coming decade. If you are a Windows developer and don’t get to work with XAML in your day job, you should learn it at night.
C# is the standard coding language for developers at ImageSource, but it wasn’t always that way. Before, VB.NET was the predominant language of choice. When converting some of the codebases over from VB.NET, we consistently run into areas where VB.NET specific commands have been used. These commands either do not exist in C# or require use of the Microsoft.VisualBasic library. Either make code conversion very frustrating when they are used.