Thursday, July 27, 2006

IE7: Microsoft's Ctrl+Tab behavior rationale

Earlier today, Aaron Sauve from Microsoft's Internet Explorer 7 team made an interesting post to the IE Blog covering the IE team's rationale for the various default behaviors in IE7 with respect to multiple tabs.

As of the latest IE7 beta (beta 3), the default behavior when using the Ctrl+Tab keystroke to switch to the next tab (or Ctrl+Shift+Tab to switch to the previous) tab is to define the "next tab" as the tab to the right of the current tab as the tabs are displayed along the top of the IE7 window.

An alternative behavior, available via a checkbox in the Advanced tab of IE7's Internet Options dialog, is to have the Ctrl+Tab switch to the most-recently-used tab instead of the "next" tab. This is how the Alt+Tab application-switch keystroke works in Windows: pressing Alt+Tab once switches you to the application you were using most recently (not the application to the right of the current application's button in the Taskbar).

As I've blogged previously, I feel pretty strongly that the "most recent" tab switching order should be the default behavior for Ctrl+Tab. It's more powerful than the "left to right" behavior, as it can be used to quickly toggle back and forth between any two open tabs.

The reasons that Aaron gives for the "left to right" order being the IE7 default are:

  • We value predictability over the more focused compare scenario.
  • We want to be consistent with other apps that use tabs throughout the system.
Regarding the predictability issue: Let's go ahead and assume for the moment that the "left to right" behavior is in fact more predictable. However, I would expect that the Ctrl+Tab keystroke would be used most frequently by more experienced users. Less experienced users would probably be most likely to activate a tab by clicking the desired tab with the mouse. Given that keystrokes such as Ctrl+Tab will most often be used by "power users," I would argue that the fact that the "most recent" switching order behavior taking a bit more time to "get the hang of" is a lesser concern.

Regarding the issue of being consistent with the behavior of other applications, I went ahead and briefly tested a few other Microsoft apps that I have on my system. Of the applications I tested, Microsoft Excel was the only application that has a "left to right"-like behavior on a Ctrl+Tab press, in this case to switch between open workbooks. (And even this example is questionable, as Excel displays open workbooks in multiple Taskbar buttons, not in multiple tabs.)

On the other hand, Microsoft Visual Studio 2005 provides an excellent implementation of "most recent" order switching on a Ctrl+Tab press, switching between open windows which are displayed in tabs near the top of the window. Visual Studio even provides an "Alt+Tab"-like window that appears while the operation is in progress showing all of the available open windows that can be switched to.

As I noted in my previous post, the most prominent app that I use currently that by default provides "left-to-right" Ctrl+Tab switching order is actually Firefox! Having a better Ctrl+Tab order by default could be nice differentiator for Microsoft.

Given that "most recent" Ctrl+Tab switching order provides more powerful behavior, and that it will be primarily "power users" using the Ctrl+Tab keystroke, I would encourage Microsoft to reexamine the decision of whether to have the "most recent" behavior checkbox under IE7's advanced options be enabled by default.

Friday, July 21, 2006

Bounds Test v2.0 Released

I've just posted a new version, 2.0, of my Bounds Test utility. This utility allows the size and position of on-screen elements to be gauged by positioning the transparent Bounds Test window over the object to be measured; the Bounds Test window then displays its size and position.

New in version 2.0:

  • The window border has been removed, allowing better visibility of items under the Bounds Test window, particuarly along the top edge.
  • The tic marks that appear along the right and bottom edges of the Bounds Test window are now labelled.
  • The Bounds Test window can now be repositioned (moved) by clicking anywhere in the window (except on a button or along the edges) and dragging.
  • The mouse wheel can now be scrolled to resize the window.

Monday, July 17, 2006

Max value of File Version in DLL Properties dialog

A mandate was recently handed down in my development organization at work that all .dll files included in a hotfix should be set with a distinct value in their File Version field, so that the file can easily be identified as a hotfix file when examined (on a customer server machine) in the future.

While preparing a hotfix this afternoon, I decided to take this a step further, and set the defect number as the 4th item in the version tuple (leaving the first three tuple values as the version of the product being hotfixed), instead of just selecting and choosing an arbitrary value for the 4th value.

The defect number in this case was 96375. In Visual C++ 6, in the project with the COM component I was building, I set the FILEVERSION value in the VS_VERSION_INFO section of the project's generated .rc file to 96375.

However, when I built the .dll and looked at the File Version value, it was set to 30839. I guessed that the value I used might have exceeded the maximum allowed value and either been set to a constant max value of 30839 (although that number didn't immediately have any meaning to me), or else "wrapped" after hitting the maximum value.

A Google search didn't reveal any information about a maximum value for FILEVERSION, so I did some brief experimentation. It didn't take long to determine that the field is apparently a 16-bit integer, with a maximum value of 65535. Assigned values of 65536 or greater just "wrap" back around to 0. So a value of 65537 yields 1, a value of 65538 yields 2... and my value of 96375 yielded the value of 96375 - 65536 = 30839.

I settled for assigning a value of 9999 to the 4th item in the FILEVERSION tuple, figuring that would be a suitable "red flag" for anyone inspecting the version number later. I also appended the text "HOTFIX 96375" to the FileDescription field's value, so that the defect number would still appear on the .dll file's Properties dialog.

Friday, July 14, 2006

New utility for download: ccc.exe ("Clipboard Character Count")

I've put a new command-line utility that I developed, ccc.exe, up for download on my utilities page.

ccc is short for "clipboard character count". This simple utility returns the number of characters currently present on the Windows clipboard.

The utility supports an optional -all switch to specify that the utility should return the length of all forms of text from the System.Windows.Forms.TextDataFormat enum, instead of just returning the count of plain text characters.

ccc.exe screen capture

Thursday, July 13, 2006

A minor formatting nicety in Visual Studio 2005

While working in Visual Studio 2005, I noticed a cool Autoformat-like behavior provided by the IDE.

I was working in a class that had a private class constant declared that I wanted to change to have public instead of private visibility. The original code looked something like: private const int MaxItems = 5; I used the ctrl+rightArrow keyboard shortcut to select a nearby instance of the keyword public, and then hit ctrl+c (Clipboard Copy), so I ended up with "public " (including the trailing space) on the clipboard.

I then double-clicked the instance of the "private" keyword that I wanted to replace to select it, and pressed ctrl+v to do the paste.

After the paste, the result was: public const int MaxItems = 5; This struck me as odd for some reason. After thinking about it briefly, I realized that I should have been left with an extra space after "public", due to the trailing space that was present on the clipboard: public  const int MaxItems = 5;

However, Visual Studio recognized what I was doing, and automatically removed the extra space for me, saving me a press of the Delete key after the paste. I tried pressing ctrl+z (Undo), and Visual Studio restored the removed space; a second ctrl+z press rolled back the Paste operation.

A very minor feature, but also indicative of the great attention to detail that Microsoft has put into the Visual Studio IDE. Pretty nice!