Kevin Dente's Blog

After doing lots of spiking and visual design on a Visual Studio 2005 web site project, I set out to write some production code for the site. I've done some TDD-based component development already on this project, but this was my first foray into writing actual logic (humble dialog style) in the web site project itself. It didn't take long to hit a big snag.

I typically like to put my unit tests in the same assembly being tested. That's always worked well in VS2003, even in web projects, so my first thought was to take the same approach in VS2005. The flaw in that plan is that "building" the web site doesn't generate an assembly that I can point the NUnit test runner at (the assembly ends up in the Temp. ASP.NET Files folder, which isn't too helpful for testing). Oops.

The only solution I've come up with so far is to put the testable UI logic in a separate assembly. Are there any other options that I'm missing?

The good news is that MS finally released their very first ever service pack for a Visual Studio .NET product.
The bad news is that it's Visual Studio .NET 2002 SP1. Presumably VS 2003 SP1 is right around the corner.

And perhaps we shall be free of The Woe at last.

I finally got a chance to start poking at the new Windows Forms DataGridView control in .NET 2.0.  I've only just started with it, but I'm finding it to be a bit of an odd beast.

The .NET 1.1 DataGrid had some major limitations. A big one is that it's fundamentally a data bound control. You can bind it to objects, making it useful without a database, but you can't really use it unbound. The DataGridView addresses this quite well. You can directly create row and cell objects, and it even supports a virtual mode. Nice.

A second big limitation of the DataGrid is that it is column oriented. Creating a column where some cells contain checkboxes and others textboxes is difficult, if not impossible. Again, the DataGridView handles this scenario well.

The design-time experience for the DataGridView is where things get a little weird. At design time, the control still appears as if it's strictly column oriented. When you add columns to the grid, you specify a column type - textbox, checkbox, button, combobox, etc. The cells of that column, however, are not restricted to be of that type. You can add a DataGridViewTextBoxCell to a DataGridViewComboBoxColumn, for example, and it works fine.

Perhaps the assumption is that if you are doing fully unbound data display, you won't use the designer to configure your columns anyway. But you still need to add columns in your code, so you basically just pick a random column type. All-in-all, it makes for an odd overall developer experience. Perhaps something like an UnboundDataGridViewColumn or GenericGridViewColumn that can be added in the designer would be helpful (you can already create a generic DataGridViewColumn, but you still need to specify a cell template, so it doesn't really address the problem).

Three other general comments on the control:

• I really wish MS had included hierarchical support. It's an extremely useful UI model at times (MS uses it in their own apps - Outlook being the most prominent example), and that one missing feature will end up forcing me to use a 3rd party control at some point, I'm sure.
• Creating a custom DataGridViewCell type looks at first glance to be more complex than I would like to see. At least, the Reflector'd implementations of the current cell types are quite complex, essentially doing all of the painting themselves. However,  I'm not sure yet if that's a requirement or just for best performance.
• I wish there was a way to plug in a custom column type to the design time experience for the control. Once you start using custom column types, you're pretty much outside of the designer.
  

Visual Studio 2005 includes some fantastic UI enhancements over VS 2003. One change that I'm not thrilled with is the Add Reference dialog. The 2003 Add Reference dialog included two lists - a list of available components and a list of selected components. You can easily add multiple references by highlighting them in the available components list and clicking Select, at which point they get added to the selected components list.

In VS2005, the dialog changes to only a single, multi-select list (a single list per tab, that is). This is bad. Multi-select lists have poor usability - especially for very long lists (and the default list in 2005 is about 9 pages, which qualifies as long in my book). Selecting multiple items from disjoint sections of the list is difficult, and its easy to accidentally unselected something that you selected three pages back with an errant mouse click. Adding both COM references and .NET references multiplies the problem - now you multiple multi-select lists. I don't know why MS decided to make this change - in my mind, the 2003 version was much more usable.

On the other hand, the references dialog now includes a "recent" tab, listing recently used references. This is a definite usability improvement.

Microsoft has announced plans for IE 7, but it's kind of hard to excited about it. Why? Because it's pretty clear that they're being dragged kicking and screaming into it. How can I get excited about using a product that Microsoft clearly isn't excited about creating? I have little faith they they will do much beyond to the absolutely minimum they need to do to stem the migration to Firefox.

Here's a nice little application - Foxit PDF Reader. It's a free, small, fast PDF Viewer. It requires no installation - just dump it into a folder and run it. It wouldn't surprise me if there were some gnarly PDFs that it couldn't handle, but for now it looks good. Adobe's Reader has become a major pig, and it's nice to have an alternative. Recommended.

There's a problem that I encounter with unpleasant frequency using a variety of Windows Forms applications. The problem is that dialog boxes don't dismiss when the escape key is pressed. It's a small thing, but for a keyboard jockey like me, it's very annoying.

The problem occurs when the CancelButton property on the Form isn't set. In a properly coded modal dialog, you set this property to be your cancel button, and the framework handles dismissing the dialog when the escape key is pressed. However, if you directly set the DialogResult of the cancel button to Cancel but don't set the CancelButton property on the form, clicking on the cancel button will dismiss the dialog, but hitting escape will not. If you're only testing with the mouse, everything appears to work as expected.

I reported this as a bug against Whidbey, but MS doesn't seem inclined to change it. So please, people, set that CancelButton property. Take pity on a poor keyboard addicted soul.

A recent post from Larry Osterman paid tribute to David Weise, one of the legendary engineers at Microsoft. He also linked to article about David, which included a picture. My first reaction was to note a striking resemblence to a well respected.NET blogger.  So you tell me - separated at birth? :)