I’ve just realised a usability problem with website log in forms. The “remember my password” checkbox is almost always below the log in button. For keyboard support, the sequence goes like this:

1. Give focus to the username field (any good app would do this for you)
2. Type in username
3. Tab to focus on password field
4. Type in password
5. Tab to focus on the log in button (with perhaps another tab to get over a cancel button)
6. Tab to focus on the checkbox
7. Space to check the checkbox
8. Shift-Tab to give focus back to the log in button with perhaps another tab if you need to skip over a cancel button
9. Space to fire the log in button

If the forms where changed to simply have the checkbox above the log in button, then the keyboard sequence would be:

1. Give focus to the username field (any good app would do this for you)
2. Type in username
3. Tab to focus on password field
4. Type in password
5. Tab to focus on the checkbox
6. Space to check the checkbox
7. Tab to focus on the log in button
8. Space (to fire the Log in button)

This would read better as the user only traverses down the screen rather than down and then up. It removes unnecessary actions and makes more sense.

I have been doing a lot of work over the last week writing xml comment documentation. I have been compiling the xml output into chm files using SandCastle, SHFB and my own SHFB wrapper application. I have been increasingly been finding that I am writing remarks that I want to reuse across different methods and properties of several classes in an assembly. Today, I had a particular property scattered among several data contracts for a WCF service that are used for the same purpose and have the same xml comments.

For several days I have been doing the very bad practice of writing the documentation and copying what I need to the other locations. I remembered reading about the <include /> element for xml comments and read up on it in more detail (see here and here). After a bit of experimentation today, I can say that the <include /> element is very powerful for three reasons:

1. You can include the entire xml comment for an item
2. You can include part of the xml comment for an item
3. You can include include elements and they will be recursively resolved

Lets look some examples. Here is my initial code:

ReSharper has a handy feature where it will identify tokens in your comments such as todo, note, bug etc. The Visual Studio IDE has a similar feature for TODO where it will identify those comments in the Task List window.

My issue with the ReSharper implementation is that it will identify these tokens even if they are in the middle of the comment rather than just at the start of the comment line. I originally posted an issue into the JetBrains Jira system thinking that this behaviour was not configurable, but then found that ReSharper identifies these tokens with regular expressions. If you open up ReSharper -> Options -> To-do Items, you will see a set of patterns identified.

The patterns defined are Todo, Note and Bug (I added Hack as a duplicate of Bug to support the default Visual Studio HACK token). I modified these regular expressions to ignore words beginning before the token. Instead, I just look for the beginning of the line. For example, the Note pattern was:

At work we have recently integrated building SandCastle documentation into our TeamBuild process using the SandCastle Help File Builder (SHFB) application. I created a wrapper application to achieve the same thing as a local dev process to help authoring the help contents.

One of the issues we had was how to add namespace documentation. The process we were using was to pass all the required information to SHFB instead of using a project file. The SandCastle project file is where the namespace documentation would normally be stored. Instead, we added the namespace documentation to an xml file stored in the appropriate documented Visual Studio project with a known file name format. The xml file was marked as to be copied to the build directory which would also make it available to team build. This file is then passed to SHFB using the -comment switch.

This may change in the near future as it looks like Eric has checked in a change to the latest SHFB beta that will do the same as the old NDoc model for namespace documentation (see here). Soon we will be able to create an internal class called NamespaceDoc in a namespace and SHFB will pull it out for us. This allows us to have documentation nicely stored in the code along with everything else.

Yep, this one bit me last week.

I had been writing some unit tests and debugging them. When the tests were finished, I kept wanting to look at the code coverage. All I would see was the message "Code coverage is not enabled for this test run". After trying lots of things and wasting 30 minutes, it turns out that code coverage is not available when debugging unit tests, even though code coverage is enabled through the testrunconfig file and that the build configuration is set Debug.

To avoid this mistake in the future, you can enable a warning message that specifically highlights the problem. Go to Tools, Options, expand the Test Tools node and select Default Dialog Box Action. There is an option called "When starting a remote test run or a run with code coverage under the debugger:". Set this value to "Always prompt". The next time that you run a unit test with the debugger attached, you will get a warning message saying "Debugging tests running on a remote computer or with code coverage enabled is not supported. The tests will run under the debugger locally and without code coverage enabled.".

No more confusion.

I have installed Vista x64 on my server which has a USB printer attached to it. I have shared this printer so that other machines on the network can use it as a network printer. I found that I could see the printer from my Vista x86 laptop, but it just wouldn’t print.

The printer properties on the printer server have some advanced properties where you can specify x86 drivers for the printer for when clients add the network printer. The problem is that the printer drivers come with Vista natively. This means that the manufacturer (HP) doesn’t provide the drivers for it as a download. After some research, I found that there is a really easy way around this issue.

The rough steps are:

1. Add a new printer to your x86 machine
2. Select Local printer attached to this machine, uncheck automatic detection
3. Select Create a new port and select Local Port
4. Enter the address of the printer (\servername\printername)
5. Select the printer make and model

Easy

This is one to remember. Paul Litwin has posted about forcing SSL gracefully on a site using a post from Paul Wilson as a reference. I’ll implement this when I set up some ssl sites that are publicly available.

I posted the other day that I wanted to create some static analysis rules for Visual Studio. I have some great ideas for several rules that I want to write in order to do two things. Firstly, I want rules to pick up common mistakes made in coding. Secondly, the rules can be used to enforce coding standards via the Code Analysis TFS checkin policy.

To enforce coding standards, I have previously written xpath and regex TFS checkin policy implementations that work off a set of defined rules. I found that the xpath policy worked really well for files like csproj and sln files. The xml in these files is reasonably simple and the xpath queries are able to easily identify data that is missing or data that shouldn’t be included. I found it was a different story with the regex policy though. It became very difficult to be able to satisfy coding standards using regex on code files. It also only allowed for analysis of content within a single file, not what outside code calls into that file or other files that the code calls out to.

Enter the static analysis rules. It turned out that these are really easy to write. In about an hour, I have created four static analysis rules and tested them. The rules so far are:

We encountered an interesting issue at work over the last week. We are writing WCF services and implementing transport security to communicate with IIS. For local development, we had certificates created by a certificate server and configured onto the local IIS. As you would expect, the certificates used the machine name for the common name of the certificate. This is after all the standard procedure.

The problem encountered is that the web application project in Visual Studio stores the url of the project in the csproj file rather than the user settings file. This is the url of the application that Visual Studio will attach to in order to debug in IIS. The url has to be a reference to the local machine. As the project is under source control, the url stored as a project setting is now put onto the machines of other developers. So if I configure the project to point to my machine using https, check in the file and another developer gets it, then their version of the project now points to my machine rather than theirs. Bit of a problem.

There were two ideas that we quickly came up with:

Jason Kresowaty has posted an incredible amount of information about creating FxCop rules. I’ll get to these one day. One rule I want to write is a rule that checks for properties on a DataContract that are not assigned the DataMember attribute.