Casting vs. Converting in .Net

I recently saw a piece of code in a project that was throwing an exception that I did not understand:

string boolString = (string)DataBinder.Eval(DataItem, "IsNew");

One would expect that boolString would be assigned the value “True” or “False” depending on the value of the IsNew property of the DataItem object. However, this through an Exception with the message: “Cannot explicitly convert bool to string”. What is going on here?

The syntax of (type)variable attempts to explicitly cast the variable into the given type. Casting does not attempt to interpret the data in the variable – it just tries to fit the object referred to by the variable into the new data type. This will work whenever the two types are somehow compatible (for example, an int can be cast into a float with no exceptions) though sometimes it may result in data loss (a float cast into an int). However, in cases where there is no connection between the two classes, casting will result in an Exception (like the one that I received above).

(There is another way to cast an object – using the as keyword. This will return a null if the cast fails, and is much faster than the explicit casting referred to above).

However, when converting an object, the conversion function has “knowledge” of the data contained in both the source and final object types, and will create the equivalent of the variable in the new data type. In the case above, using the System.Convert.ToString() method in place of the attempted cast to (string) would have worked fine. This is because the ToString method “knows” that a bool cannot be case into a string – but it also knows what the equivalent string to each value of a bool will be, and is able to process the operation accordingly. In this case, reflector uncovers the following code (in the Boolean class):

public string ToString() {
    if (!this) {
        return "False";
    return "True";

This is obviously a very simple type conversion. However, there are many more complex conversion utilities built into the .Net framework (accessible through the System.Convert class – see the DateTime.ToString conversion for an example of this. Also see the IConvertible interface). While conversions can be more expensive to run, since they are strongly typed, they are checked at compile time, and when used properly are more reliable to use when producing stable code. (See the MSDN article on Casting and Type Conversions for more info).

Detecting Application Idle State in Windows Forms

On a recent project, I had the need to detect whether or not the application is idle, and if so, for how long has the idle state persisted. Idle in my case is defined as no mouse movement or keyboard activity when any of the forms of the application are in focus. If a different program is in focus, I define this as being an application-idle state (for my app), regardless of whether or not there is input activity from keyboard or mouse.

On researching the subject, I found several approaches. The main approach I have seen is to use the static Application.Idle event. This event fires whenever “application finishes processing and is about to enter the idle state” – In other words, whenever the application’s message queue is empty. The problem with this approach is that this event fires a lot, so much that it becomes impractical for tracking idle state the way that I need it (it doesn’t help that any Timer operating to track how long the idle state persists would set off Application.Idle, further complicating the situation).

The other approach that I have seen is to set up some Windows hooks to detect mouse and keyboard activity. I have zero experience operating with the Windows API, so thankfully, I found a post by Johan Danforth that gives some working code for doing exactly what I needed: Detecting Idle Time with Mouse and Keyboard Hooks. I integrated the code with my application and tested it out and it worked great.

There was one problem however: this code detects idle time for all applications. In other words, if your application is open but not in focus and you use your mouse or keyboard, the code changes your application status from Idle to Active. For my purposes (see definition if idle above) this is not good enough. So I inspected different properties of the System,Windows.Forms.Form class to see what could tell me whether or not a given form is active. The first candidates were Focused, TopLevel, TopMost and Visible, but none of these did the job. The property that ended up telling me exactly what I needed to know is ContainsFocus. This is a property of the Control class (from which Form inherits) and it “Gets a value indicating whether the control, or one of its child controls, currently has the input focus”. (Focused is not good enough, since it only returns true when the form itself has focus, but returns false when a child control contained within the form has focus).

I also needed to detect whether any of the secondary forms of my application had focus (since I could have more than one window open at a time, only one of which could have focus). Here is the code that I used:

private bool DoesApplicationHaveFocus() {
  bool hasFocus = false;
  if (ContainsFocus) {
    hasFocus = true;
  } else {
    FormCollection forms = Application.OpenForms;
    foreach (Form f in forms) {
      if (f != null && f.ContainsFocus) {
        hasFocus = true;
  return hasFocus;

Repeater Failure and Disappearance on Row 28

I was working on an application (1.1) the other day, changing the UI display of a page. This page basically consisted of a Repeater being populated with data from the DB, and binding javascript actions and styling info to the different rows to be output (each overall it was producing a Table, and each item was a TableRow). Although the look-and-feel was going to be changing, as well as the manner in which the data was to be retrieved, the actual data set up and binding was to remain the same as it had been. Piece of cake, right?

The programming was straight-forward enough. When I first tested the feature on a few records, it worked fine. However, when I tested it on more records, it didn’t work. And when I say that it didn’t work, I am not saying that I got back some ugly .Net exception. I mean that the HTML output by the server was completely devoid of the Repeater element. It was as if it just did not exist. Somehow, when I tried the load the page with a large number of records,  some weired thing happened in IIS that just completely abandoned the rendering of the Repeater element without even providing an error message. Completely weird.

After a couple of hours of debugging, I was able to determine that the error was not related to any specific data item. Rather, it always happened when outputting the 28th DataItem in the Repeater. 27 worked fine. 28 killed it. Racking my brain (and Google), I couldn’t find any reason why this would be happening. This exact same repeater worked fine on other pages, on the live site. There was no reason I could think of why this type of failure would happen, and why it would happen here.

My coworker SeanS suggested that perhaps this was related to my dev environment, perhaps some faulty memory or something like that. There was nothing else to go on and this did explain what was going on (and I knew that the feature worked for <28 rows), so I proceeded with development. And lo and behold, when I uploaded my changes to the staging site yesterday, it worked with any number of rows without any hitch-up.

Moral of the story: weird things happen on web servers and on dev machines. Not every error that you get is related to code (especially if the error is reported by the absence of output rather than an exception). If something like this is happening to you (and it is not reproducible on other platforms), it may very well be environment-related. Test this out before wasting more time and energy trying to sort it out through the code.

Enumerating a Dictionary<> Object

In C# using .Net 2.0+, there is now built-in support for Generics collections using the System.Collections.Generic namespace. I use the List type most often, as a strongly-typed substitute for the ArrayList. Since it is strongly-typed, you now have design-time type-checking for enumerations like this (no casting necessary):

List<int> Foos = new List<int>();
foo.Add(new foo(1));
foo.Add(new foo(2));
foreach (foo f in Foos) {

The second-most useful Generic (in my opinion) is Dictionary. This is a strongly-typed hashtable, where you can determine the types of both X (the Key) and Y (the Value). Like other Generic collections, the Dictionary object type is also Enumerable (meaning that you can use statements like foreach to automatically parse its contents in order). However, since there are two different types of value stored in a Generic Dictionary object, how do you call an strongly-typed enumeration statement like foreach? This is done by referencing each pair of values as a KeyValuePair object (which is another type of Generic supported by System.Collections.Generic”) and can be performed as follows (ref)

Dictionary<string, int> PhoneNumbers = new Dictionary<string, int>();
PhoneNumbers.Add("Jones, Jim", "800-555-2312");
PhoneNumbers.Add("Smith, Beth", "324-555-6742");
foreach(KeyValuePair<string, int> personNumber in PhoneNumbers) {
  Console.PrintLine(personNumber.Key + "\t" + personNumber.Value);

Declaring Custom Events in User Controls

I am constantly needing to search my code to find the exact syntax for how to do this, so for future reference (for myself and anyone else who finds this useful), to declare and call an event from a custom user control or inherited control:

public class CustomEventArgs : EventArgs {
  public CustomEventArgs(int propValue) {
    _propValue = propValue;

  private int _propValue;
  public int PropValue {
    get { return _propValue; }

public delegate void CustomEventHandler(object sender, CustomEventArgs e);
public event CustomEventHandler CustomEvent;

public void Function() {
  // Do Stuff
  if (CustomEvent != null) {
    CustomEventArgs e = new CustomEventArgs(x);
    CustomEvent(this, e);

If you don’t need a CustomEventArgs class, just use the built-in EventArgs instead.