Use C# ?? null coalescing operator for parsing request query string parameters

I’m a big fan of succinct code, especially when it comes to satisfying requirements that are ultimately trivial but redundant. That being said, I think the following is the best way to parse query string parameters:

    string sParam = "t"; 
    string sResult = string.Empty; 

    sResult = (Request.QueryString[sParam] ?? "").Trim();

    if (sResult != "")
    {
      // Do something
    }

If the request string param is null, the string returns “”. If the request string param has a value, we snag it and Trim() to ensure that we get what we want and nothing else (this is important, especially since users can toy with the param values and send values with unexpected extra spaces). The idea here is to encapsulate as many “checks” into a simple, quick parse to ensure that you don’t have to back track and validate anything (insofar as handling null or empty data). Notice, also, that I use the Trim() method outside of the “coalescing” routine – this is because if the Request.QueryString[] call returned null, Trim() would throw an object reference exception.

Some other methods you might use for accomplishing the same thing:

Example 1

      string sParam = "t";
      string sResult = string.Empty;
      
      if ((Request.QueryString[sParam] != null) && (Request.QueryString[sParam].Trim() != ""))
      {
        sResult = Request.QueryString[sParam].Trim();
      }

      if (sResult != "")
      {
        // Do something
      }

Example 2

      string sParam = "t";
      string sResult = string.Empty;      
      
      sResult = (null != Request.QueryString[sParam]) ? Request.QueryString[sParam].Trim() : "";

      if (sResult != "")
      {
        // Do something
      }

Example #1 and #2 will each give the same end result and functionality as the null coalescing approach sketched above, but at any rate they contain a lot of redundancy. The null coalescer is the easiest approach of the proffered bunch, I think. 

For more information on the C# null coalescing operator and some other interesting uses (e.g. using it with LINQ), check out: http://weblogs.asp.net/scottgu/archive/2007/09/20/the-new-c-null-coalescing-operator-and-using-it-with-linq.aspx

BalloonTipTitle and BalloonTipText max length

NotifyIcon.BalloonTipText max length = 255 characters
NotifyIcon.BalloonTipTitle max length = 63 characters

Source: Trial and error.

Good luck finding these specs anywhere. Seems to be one of the lesser documented items in the Windows API (or it requires a very specific search term). Funnier still is you won’t get any compiler errors in Visual Studio 2005/2008 if your string is longer than the above mentioned lengths – you’ll just have to wait for your balloon tip to get cut off when it’s displayed.

asp.net: Modify Request.QueryString

Suppose you needed to modify the query string passed in a given URL before redirecting to another (or even the same) page. For example, imagine you needed to take:

/default.aspx?name1=value1&name2=value2&color=red

and turn it into something like:

/default.aspx?name1=valueX&name2=valueY&colorcode=red

I’ve seen this done with loops, new URI’s, and so on to get around the query string read-only “problem”, but most implementations like these are fairly arduous, not to mention error-prone. Given all of the idiosyncrasies involved with the Request.QueryString object (e.g. is read-only, is a modified version of the NameValueCollection object, etc.), I still think the the following approach is the best bet:

using System.Collections.Specialized;

public partial class ModifyQueryStringExample : System.Web.UI.Page
{
  protected void Page_Load(object sender, EventArgs e)
  {
    // Create a new (editable) NameValueCollection using the existing (read-only) collection
    NameValueCollection objNewValueCollection = HttpUtility.ParseQueryString(Request.QueryString.ToString());
    objNewValueCollection.Set("name1", "valueX");
    objNewValueCollection.Set("name2", "valueY");
    objNewValueCollection.Add("colorcode", objNewValueCollection.Get("color"));
    objNewValueCollection.Remove("color");

    string sRedirect = Request.Url.AbsolutePath;
    string sNewQueryString = "?" + objNewValueCollection.ToString();

    sRedirect = sRedirect + sNewQueryString;

    Response.Redirect(sRedirect, true);
  }
}

Some notes:

1. All other parameters passed in by the original query string will be carried over untouched. For example, if the original query string also included something like “id=1234&status=1”, these values would persist into the new redirect even while the other name/value pairs have been modified.    
2. The NameValueCollection Set() method allows nulls, so it will work regardless of whether or not the key you’re looking for actually exists. If the key exists, the value will be appended accordingly. If the key does not exist, it will be added with the appropriate value. This time around I chose to use the Add() method for readability since I know for a fact that this routine will always be adding a key (“colorcode”) rather than appending one.
3. All NameValueCollection methods that use a text compare are case-insensitive, as per msdn: http://msdn2.microsoft.com/en-us/library/system.collections.specialized.namevaluecollection.namevaluecollection.aspx 
4. The NameValueCollection ToString() method automatically inserts “=”/”&” characters for you when/where appropriate. The NameValueCollection instance returned by HttpUtility.ParseQueryString is an HTTPValueCollection (a specialized NameValueCollection type), so its ToString() method will automatically insert “=”/”&” characters for you where appropriate. Although this is undoubtedly a nice feature, one can’t help but mention that the surprisingly convenient behavior just described is not immediately obvious given the msdn documentation at http://msdn.microsoft.com/en-us/library/system.web.httputility.parsequerystring.aspx. Nevertheless, the implementation is made clear by evaluating any NameValueCollection.ToString() against an HTTPValueCollection.ToString(). The former will return the object’s string representation (‘System.Collections.Specialized.NameValueCollection’) while the latter, of course, will provide a legitimate name/value collection with the applicable field-value separators. Interestingly, the only way to get an HTTPValueCollection instance in the first place is to use HttpUtility.ParseQueryString. No doubt a quirky matter. For further discussion on the issue, visit http://msmvps.com/blogs/paulomorgado/archive/2008/07/15/make-the-httpvaluecollection-class-public-and-move-it-to-system-dll.aspx