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.

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.

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.

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.

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!

Fix: "This file is not in the standard Zip 2.0 format" (Winzip)

Earlier today, I was attempting to copy a large VMWare virtual machine image file to my test machine at the office. I was able to copy the compressed .zip file, about 3 GB in size, to the machine with no trouble. However, when I tried to use Winzip to decompress the file, I got an error: "skipping: [filename] this file is not in the standard Zip 2.0 format":

I had previously set up the same virtual machine image from the same .zip archive on another machine. I tried copying the uncompressed image file (about 6 GB in size) from that machine, but got another error, this time from Windows Explorer: "there is not enough free disk space".

I checked, and I did have only about 5 GB free. At this point I figured that the Winzip error might have been a symptom of the insufficient free space on the drive, with the weird error text possibly being attributable to the large size of the file.

I cleared some large files off the drive -- mostly old SQL Server databases and old Virtual PC images -- and got up to over 20 GB of free space. However, when I retried the copy operation, I still got the same error from Explorer about insufficient free disk space.

A quick Google search on that error revealed that the problem might be that if the test machine was running the old FAT32 filesystem instead of the modern NTFS system, that error message could result, as FAT32 supports file sizes only up to 4 GB. I also noticed that Winzip was reporting the uncompressed size of the virtual machine image file as 4 GB instead of the correct 6 GB, which seemed to be a symptom consistent with the .zip archive file being stored on a FAT32 drive. The test machine was indeed running FAT32 (checked by opening My Computer from the desktop, right-clicking the C drive, and selecting Properties from the context menu) and I had no reason not to upgrade it, so I went ahead and ran convert.exe to do the upgrade to NTFS.

When the upgrade to NTFS eventually finished, I once again tried to copy the uncompressed machine image across the network to the test machine, but the network itself decided not to cooperate at this point, and the transfer was progressing extremely slowly (even given the 6 GB file size). So at that point I turned my attention back to uncompressing the image from the .zip archive, figuring that it would now work since the filesystem was now NTFS and the disk had sufficient free space.

To my surprise, I continued to get the same error about "Zip 2.0" format. I also noticed that Winzip was still reporting the uncompressed VM image file size as 4 GB instead of the correct 6 GB. Earlier I had ignored the www.winzip.com/zip20.htm URL mentioned in the Winzip error message, assuming it would be similarly unhelpful to the Microsoft site links that Windows error dialogs that come up when an app crashes occasionally provide, but at this point I figured it was worth a look.

The text on the linked page isn't terribly helpful, mostly text encouraging an upgrade to Winzip 10 (which isn't a free upgrade even for registered/paying users of Winzip 9 and previous versions). However, it does mention something about a particular compression method, "bzip2", requiring Winzip 9 or later.

At this, I checked the Winzip version numbers (on the app's Help | About menu) on both of my machines. On the machine where I had previously successfully uncompressed the large virtual machine image file, Winzip 9 was installed; on the test machine where I was having trouble, Winzip 8 was installed. Aha!

I upgraded the test machine to Winzip 9. Once that was done, I was able to uncompress the image file from the .zip archive with no trouble.

So, on the "this file is not in the standard Zip 2.0 format" error from Winzip, the thing to do is to upgrade to Winzip 9 if you're running an earlier version. It took me a while to get that figured out, but at least I had a reasonable excuse to spend a little time to get the disk on my test machine cleaned up and upgraded to NTFS along the way. :-)

Usability: When the "Close" icon doesn't.

On the Windows platform, there are several icons that can appear on the buttons at the upper-right corner of an application window that have a well-defined, standardized functionality. Examples include a horizontal line to minimize the window, a single rectangle to maximize the window, and, perhaps most commonly, an "x" to close the window.

In most cases, when then "x" button is clicked for the main window of an application, the expected behavior is that the button click closes that application. However, for some applications, a click on the application window's "x" button, instead of closing the application, instead performs a "minimize to system tray" operation. Applications that display an icon in the Windows system tray (or "notification area") often (but not always) have this behavior. Microsoft ActiveSync is an example of such an application:

In general, since the "x" button cannot be used to close (exit) such applications, users wishing to close the application must employ some other (non-standardized) method, such as a menu pick in the application window, or a menu pick in the right-click menu of the app's system tray icon. (Some system tray apps don't allow themselves to be closed at all short of manually killing their process, but that's a separate issue!)

It would be nice if a new standardized button icon were used in place of the "x" icon for the "minimize to system tray" functionality. I propose using a small horizontal line in the lower-right corner of the button; this would follow the convention of the left-aligned horizontal line that appears at the bottom of the standard "minimize" icon. Here's a quick sketch I put together in mspaint.exe:

When appropriate, application designers could use the new "minimize to system tray" icon alongside a standard "x" icon, allowing users to easily either minimize the app to the tray or exit it, as desired. This would be an improvement over the current state of affairs where designers must choose which of two standard behaviors -- "close" or "minimize to tray" -- to assign to the "x" button of the main application window.