Category Archives: Code Junky

What Lies Beneath Enum types

Enum types are used extensively within .NET framework to represent a group of named constant integers (default underlying type of enum elements is int) that you can use as method arguments, return values, etc; to make your program more readable and maintainable.

Once your codes are compiled into IL, all enum(s) that you use in your codes will be substituted with the underlying value. Therefore, knowing the actual values of enum elements is useful in some scenarios such as when reading the IL of a disassembled assembly.

This can be achieved easily using the reflection facility provided by .NET framework. Let say you want to see what’s inside the System.Data.DataRowState enum type, you can write and execute the following codes to list all the enum elements and the underlying integer value that each element represents:
Type dt = typeof (DataRowState);
foreach (string s in Enum.GetNames(dt))
{
    Console.WriteLine("{0} = {1}", s, Convert.ToInt32(
        Enum.Parse(dt, s)));

These codes will basically print the names of all members for the enum type in question, and the underlying integer values next to the names.

C# Property Access Modifier

C# property can be assigned an access modifier (public, private, protected, or internal) to control the accessibility of that property against an external caller. Prior to .NET 2.0, we could not declare a property with different access modifier for the accessor (get and set). This is somewhat limiting, considering that sometimes we want the set operation to be less public than the get operation. If you want to do that in C# 1.x, you have to do this (which is not pretty and defeats the purpose of Property syntax):

public string Name
{
    get
    {
        return name;
    }
}

internal string SetName(string name)
{
    this.name = name;
}

Luckily, the problem was recognized and addressed in C# 2.0 with the introduction of “Asymmetric Accessor Accessibility”. So now you can do this:

public string Name
{
    get
    {
        return name;
    }
    internal set
    {
        name = value;
    }
}

There are some restrictions for this, the most important ones being:

  • The accessor (get or set) access modifier must be more restrictive than the property access modifier.
  • Accessor modifier can only be defined when a property has both get and set accessors and the accessor modifier is only permitted on only one of the two accessors.

Just in case you’re not up to date.

How Does Your Browser Know that It’s Not The Default?

On Windows system, how does your browser tell that it’s currently not the default? Prior to Windows Vista, this information is stored in the registry under HKEY_CLASSES_ROOT hive, the usual place where all shell associations are kept. The default browser is maintained under HKEY_CLASSES_ROOT on per-protocol basis (as well as per file type basis, but I’m only interested in the protocols since we use browsers most of the time to access online resources, not offline). The convention for registry locations, where protocol-application associations are stored; is “HKEY_CLASSES_ROOT\[protocol]\shell\open\command “. Substitute [protocol] here with http, https, ftp, gopher or other protocols commonly supported by your favorite browser.

For example: if I want to know what is the default program for opening http protocol, then I’ll look at the registry value of “HKEY_CLASSES_ROOT\http\shell\open\command”. If I go to Start menu, click Run, type “https://newoldthing.wordpress.com” and then hit Enter, the URL will be opened with the application of which command line is registered in this registry value. As simple as that.

The next question will be, whether the default browser is maintained on per-user basis or it’s a system wide setting. If it’s maintained on per-user basis, then if user A set his default browser, then it will not change the default browser for user B or C. This would be somewhat the desired behavior, don’t you think? Imagine a family whose members are computer versed or so they thought, sharing one PC, and they constantly have fight over IE vs Firefox vs Opera. You don’t want the default browser to be system wide setting in that family’s PC.

But unfortunately, the answer is not straightforward. The default browser setting can be both per-user and system-wide. To understand this, you need to understand HKEY_CLASSES_ROOT hive. There’s no better place to start than MSDN documentation. In summary, there are 3 important concepts about HKEY_CLASSES_ROOT that we have to keep in mind:

  1. The HKEY_CLASSES_ROOT key provides a merged view of “HKEY_LOCAL_MACHINE\Software\Classes” (contains default settings that can apply to all users on the local computer) and “HKEY_CURRENT_USER\Software\Classes” (contains settings that apply only to the current interactive user).
  2. The user-specific settings have priority over the default settings.
  3. If you write values to a key under HKEY_CLASSES_ROOT, the values will go under:
    • HKEY_CURRENT_USER\Software\Classes; if the key exists under HKEY_CURRENT_USER\Software\Classes.
    • Otherwise, HKEY_LOCAL_MACHINE\Software\Classes.

Windows basically requires browsers to do the right thing to make the settings per-user basis instead of system-wide. In ideal scenario, before writing the default browser settings to HKEY_CLASSES_ROOT, browsers need to check if the key already exists under HKEY_CURRENT_USER or not. If the key exists there, then writing to HKEY_CLASSES_ROOT will be equal to committing to HKEY_CURRENT_USER; meaning that the settings will only affect the current interactive user and not other users. If the key doesn’t exist, then no question the key must be written under HKEY_CURRENT_USER instead of HKEY_CLASSES_ROOT. However, most (if not all) browsers basically write to HKEY_CLASSES_ROOT blindly, and since the protocol-association registrations do not exist under HKEY_CURRENT_USER by default, that means browsers write the settings to HKEY_LOCAL_MACHINE all the time. That is not only annoying and disruptive, the attempt to overwrite default browser may ultimately fail as well.

Consider the scenario of standard or limited user accounts. They don’t have write access to HKEY_LOCAL_MACHINE\Software\Classes. So if standard user says “Yes” when asked by browser X to set X as default browser, and X writes the settings to HKEY_CLASSES_ROOT which ultimately passed-through to HKEY_LOCAL_MACHINE; the registry write operation will fail. As a result, browser X will ask the same question next time it’s launched by this standard user. More frustration for the user!

Realizing these bad-eggs and with good intentions to prevent users from stepping on each other’s toes, Windows Vista introduces new way of registering default browser. It’s part of the new feature called Default Programs. It’s different to Windows XP’s SPAD (Set Program Access and Defaults) in that Default Programs is primarily controlled at the per-user level instead of per-machine level (out of the box! And does not rely on 3rd party programs to do the right thing). As part of this Default Programs, the default browser settings are now stored under “HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\ Associations\UrlAssociations\[ftp|http|https]”. Windows Vista’s shell will launch a URL with an application associated with the URL’s protocol based on the value of these registry keys. Browsers that were not aware of this change broke on Vista, they were simply unable to set itself as default browser (they saw themselves as default browser although shell didn’t think so because the twos were looking at 2 different registry keys).

Windows shell team introduced a new shell object called ApplicationAssociationRegistration to allow application registering itself as default for a particular type or protocol, as well as querying the current default. This shell object is only available on Vista, and therefore incorporating that in the code that is also targeted for previous Windows versions needs to be done with care. Tomorrow I’ll talk about how to use ApplicationAssociationRegistration shell object in a code base that is not exclusively targeted for Vista.

7 Habits of Highly Effective Programmers

You heard about the "7 Habits of Highly Effective People" before, now it's time to be specific and unfold the secrets of 7 Habits of Highly Effective Programmers. Good read! Check it out.

How To Make Column-Mode Selection in Visual Studio

All text-editors on Windows, including Visual Studio; generally operates in line-mode (and implicitly stream-mode too).

Stream mode selects text in a “stream”, beginning with the first character selected and ending with the last character, just as if you were reading the text. Line mode selects full lines of text. Both of them are characteristically equal in terms of their modus operandi, i.e. they work in lines; it’s just a matter of how much texts are covered by the selection (either all or some).

There’re some circumstances where you want to select in columns instead of lines. Selecting text in column mode is similar to drawing a rectangle around the text you wish to select. See the differences in the following figure:

Selection Modes

Many people do not know about the column-mode selection in Visual Studio, but it’s just as simple as holding the ALT key while rubberbanding your text (selecting text by dragging the mouse). Pretty handy, huh?