• The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine.
• The ‘Microsoft.ACE.OLEDB.12.0′ provider is not registered on the local machine.

Then it is necessary to install 2010 Office System Driver Beta: Data Connectivity Components on the server (the reason for this is the old Jet4.0 drover does not exist for 64 bit, and the ACE driver needed to read the newer formats is not installed by default). If you are using a version of Windows with UAC enabled, be sure to do this as Administrator.

After installing the components, use the following connection string formats (from the page linked-to above):

• Using OLEDB, set the Provider argument of the ConnectionString property to “Microsoft.ACE.OLEDB.14.0”. Example: “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=Path_To_File”
• Using OLEDB and connecting to a Microsoft Office Excel file, add “Excel 14.0” to the Extended Properties of the OLEDB connection string defined in the previous bullet point.
• Using ODBC:
  • Connecting to Microsoft Office Access (.mdb or .accdb): set the Connection String to “Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=path to mdb/accdb file”
  • Connecting to Microsoft Office Excel (.xls, .xlsx, .xlsb): set the Connection String to “Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=path to xls/xlsx/xlsm/xlsb file”

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).

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;
        break;
      }
    }
  }
  return hasFocus;
}

• Standard DateTime Format Strings
  

  d/D	short/long date
  f	long date, short time
  F	long date, long time
  g	short date, short time
  G	short date, long time
  t/T	short/long time

• Custom DateTime Format Strings
  

  d	day 1-31
  dd	day 01-31
  ddd	abbreviated day name
  dddd	full day name
  h	hour 1-12
  hh	hour 01-12
  H	hour 0-23
  HH	hour 00-23
  m	minute 0-59
  mm	minute 00-59
  M	month 1-12
  MM	month 01-12
  MMM	abbreviated month name
  MMMM	full month name
  s/ss	seconds (0/00)
  t	am/pm
  y/yy	year

• MS Reporting Services Date Formatting
• Blog post from SteveX on using DateTime.ParseExact

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.

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

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);
}

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.

1. This one is built-in to .Net, but can be slow at times (and some people do not like the way that it handles capitalizations of Unicode strings)

System.Globalization.CultureInfo.CurrentCulture.TextInfo.ToTitleCase(value);

2. Based on Regular Expressions (2 examples found here)
3. Some other home-baked implementations, mostly scanning through the string for whitespace, and capitalizing new words as they come up.

Am I missing anything?

Really, all that I should have to do is to customize the function for my projects codebase, migrate some of the ASP.net aspect to a WinForms environment, and hook it up to my UI. Yet, as I am going through this code, trying to make sense of what is going on, I find myself having to delete/modify/rewrite much more of the code than I should be doing. Although some of this is to be expected, much of it has to do with poor programming practices that if maintained lead to future difficulties with maintenance, poor readability, logic errors and bugs and are detrimental to debugging and testing. True, I have not found so many examples that are worthy of public exhibition, but I have received an education in how poor coding practices can effect a section of code long after the original programmer has completed his (or her) work.

A sampling of some of the things that are currently causing me grief:

Not enclosing the body of an if statement (or other control-body) in brackets

DoWork();
foreach (string s in List<string>)
   if (s == "a")
      DoA();
   else if (s == "b")
      DoB();
DoWork();

True, this code compiles and works. And thanks to Visual Studio’s automatic indentation system, you can sort of tell what items belong in what structure by looking at the indentation. But it is confusing. And if someone adds one more line of code somewhere in there without thinking about it, you are going to have big problems on your hands. (What should be done: use open- and close-brackets very liberally)

Leaving superfluous and redundant code in production

I found two different functions, each with hundreds of lines of code, each intended to perform the same function. One of them is used, one of them is not. Yet, neither of them is commented out, and there is not indication given that one of them is not used and is not necessary. This doesn’t break anything, but is a headache for those who have to deal with the code. (What should be done: if there is a whole section of code that is redundant, either comment it out or delete it)

Mixing different return types in the same functions

private object GetText(string s) {
   if (s == "a") {
      string t = a.ToLower()s
      return t;
   } else {
      StringCollection x = new StringCollection();
      x.Add(s);
      return x;
   }
}

private void Process() {
   // Do Work
   if (a) {
      txtName.Text = (string)GetText(x);
   } else {
      txtName.Text = ((StringCollection)GetText(x))[0];
   }
}

The GetText function above can return either a string or a StringCollection, depending on the value of the parameter. Although this works if the programmer knows exactly what is going on and makes no mistakes, it is very error-prone and is a nightmare for maintenance. (What should be done: find some way to use one return type in a function. If this is not possible, create two separate functions. If this is not possible, use reflection to test the value of a returned object before using it in the guise of its assumed type)

Using strings instead of enums

private void DoStuff(string size) {
   switch (size) {
      case "small":
        // work
        break;
      case "large":
        // work
        break;
   }
}

Like the previous examples, this code compiles and works. One would presumably either call this function with DoStuff(“small”) or DoStuff(“large”). But what if you use a different parameter value. DoStuff(“Small”) compiles but fails at runtime, as does DoStuff(“medium”). However, if instead of using a string parameter, you create an enum called Sizes with values “small” and “large”, you guarantee that only valid values can be passed to the function.

Misspelling the product name in the assembly

This doesn’t really affect anything. It is just sloppy. If your program is called Writing Workshop, please do not create a namespace in your code called “ritingworksop”. It is just annoying and reflects badly on your understanding of the application that you are creating.

The most obvious choice for this in the Windows.Forms control library that is part of the .Net 2.0/3.0 framework is the RichTextBox control. This control gives you a textbox that has functionality similar to the WordPad application found in the Windows OS. It can display formatted pretty well. Aside from the fact that you have to handle all formatting of text in code, RichTextBox it has one major shortcomings: It can only input/output plain text or RTF encoded text. If I wanted to use a RichTextBox control to edit HTML, I would need some way to translate from the source HTML (stored in the DB) to RTF (to be displayed in the RichTextBox) and then back to HTML (to be stored again in the DB). Although I found some components from Sautin Software that seem to do the job, they cost money that I would rather not spend, and add a layer of complexity to my code library that I would rather avoid.

I found a couple of controls that extend the RichTextBox in order to allow input of HTML: An extended RichTextBox to save and load “HTML lite” files by Oscar Londoño (Code Project – For .Net 1.1/VS 2003) and RichTextBox that Displays XHTML by Eric Voreis. Both of these controls extend the RichTextBox control in the Windows.Forms library so that it can translate on the fly between RTF and HTML code (so you can input HTML code, see it displayed in the RTB and export HTML code). However, both are old and only support a small subset of HTML tags (although this can be extended in the source, it required knowledge of how RTF works). Also, since they use a RichTextBox control for editing and display, the display is similar but not identical to what you would get using a WebBrowser.

The next method that I found for providing this type of error is HTML Editor by Carl Nolan (Microsoft Consulting Services). This control (written in 2003 for .Net 1.1) modifies a WebBrowser control to allow inline editing and display of HTML. It is professionally written, provides support for many HTML tags and does just about everything that I need (and is free). The one problem is that it is pre-.Net 2.0. It uses a WebBrowser control from before this control was included as part of the Windows.Forms library in .Net 2.0 and thus has to reference Win32 calls and perform other types of acrobatics in order to get the control to function properly. This matters to me because it decreases portability of the control (using Mono, for instance), and makes it harder for me to customize and edit.

The control that I am using in the end employs the same general idea used in HTML Editor, but takes advantage of new features (like the native WebBrowser class) provided by the .Net 2.0/3.0 framework and and Visual Studio 2005. A Windows Forms based text editor with HTML output by Kevin DeLafield uses a WebBrowser control with modified functionality to allow WYSIWYG display and editing of HTML text. It provides all of the functionality that I am looking for and allows for easy modifications and customizations in Visual Studio 2005. I recommend that anyone in need of similar functionality take a look at this control.