Workaround: Can't focus Google Toolbar with Alt+S in Firefox 2.0

In Firefox 2.0, a new top-level menu, "History," was introduced, with an accelerator keystroke of Alt+S. Unfortunately, this conflicts with the Alt+S keystroke used to access the Google Toolbar for Firefox. In Firefox 2.0, a press of Alt+S activates the History menu instead of setting the focus to the Google Toolbar.

A somewhat extreme, but effective, workaround for this is just to disable (remove) the History menu. This can be done by adding the following code to your userChrome.css file:

/* For now, hide the new Firefox 2.0 History
menu because Alt+S collides with Google toolbar 
search field */
menu[label="History"] {
   display: none !important;
}

Help on editing your userChrome.css file is available here: http://www.mozilla.org/support/firefox/edit

Google has indicated (in this Google Groups thread) that a better solution should be forthcoming. Hopefully it won't be too long! Until then, I can live with using the Ctrl+H History sidebar and the back button dropdown menu session history to duplicate most of the History menu's functionality.

Update 6/8/2007: The keyboard shortcut Alt+G now works in the latest version of the Google Toolbar for Firefox 2.0 to set the focus to the Google Toolbar's search field. This isn't quite as handy to reach with the left hand on a standard keyboard (compared to Alt+S), but it does bring the Google Toolbar for Firefox into step with the Toolbar for IE, which has always used the Alt+G shortcut to set the focus to the Search field.

(Alt+G wasn't used in older versions of the Google Toolbar for Firefox because it conflicted with the shortcut for the Firefox 1.x Go menu.)

"Address Bar [Url] is currently unavailable" bug in IE7

I just ran across the following weird behavior in Internet Explorer 7:

• Open a new IE7 window.
• Fairly quickly (before the homepage begins loading), paste a valid URL into the address bar and press enter.
• An error message appears: Caption "Address bar", text "[Url] is currently unavailable."

The error doesn't occur if I wait a second or two after the windows opens before navigating to the new URL.

This may seem like a fairly contrived set of steps to take, but I wasn't hunting for IE7 bugs when I ran across this; I was just using the browser normally. It's a series of steps I do fairly frequently to quickly bring up a URL in a new IE window via keyboard: copy an URL to the clipboard, open the new IE window (Winkey | down arrow | Enter -- IE is the top item in my Windows XP Start menu), Alt+d to set the focus to the address bar in the new IE7 window, Ctrl+v to paste the URL, enter to navigate to the URL.

I have to think this behavior of IE7 is a bug -- at least, it doesn't seem like something that should be classified as "working as intended" or "by design"! And I never saw this behavior in several years of using IE6.

DragDropEffects.Link bit not included in DragDropEffects.All value (.Net 2.0)

I just spent a frustrating few minutes trying to figure out what looked to me like some unexpected behavior in the code (C# 2.0) for a drag/drop operation in a Windows Forms component. In the handler for a DragOver event, I was setting the Effect property of the DragEventArgs argument to DragDropEffects.Link, but then subsequently in my GiveFeedback event handler, the Effect property of the GiveFeedbackEventArgs was coming back as None.

In other words, I was essentially doing this in my DragOver event handler:

private void HandleDragOver(object sender, DragEventArgs e)
{
    e.Effect = DragDropEffects.Link;
}

And then seeing this result in my GiveFeedback event handler:

private void HandleGiveFeedback(object sender,
  GiveFeedbackEventArgs e)
{
    if (e.Effect == DragDropEffects.Link)
    {
        // (Execution not making it here -- value of 
        // e.Effect is DragDropEffects.None!)
    }
}

I figured out that the problem was that I was using this line of code to start the drag operation:

DoDragDrop(dragData, DragDropEffects.All);

See the problem? I didn't, at first.

The DragDropEffects enumeration is a FlagsAttribute enum with the following members: All, Copy, Link, Move, Scroll, and None. At the time that I coded the DoDragDrop line of code above, I had made the assumption that the All value of the enumeration was defined as:

Copy | Link | Move | Scroll

That is, a bitwise OR combination of all of the members of the enum aside from the None member.

However, looking that the value of System.Windows.Forms.DragDropEffects.All in the Visual Studio debugger, the value is actually defined as:

Copy | Move | Scroll

The Link member is not present! This is why my GiveFeeback event handler was failing to recognize DragDropEffects values of Link -- Link was not actually being specified in the allowedEffects parameter (argument 2) of my DoDragDrop call.

Since what I really wanted to accomplish was to support Move and Link operations, I changed my DoDragDrop call to:

DoDragDrop(dragData, DragDropEffects.Move | DragDropEffects.Link);

This did have the desired effect of getting my GiveFeedback event handler method to support DragDropEffects values of Link.

The fact that DragDropEffects.All does not include the value for Link isn't clearly spelled out on the MSDN help page for DragDropEffects. The description for the All member does say "The data is copied, removed from the drag source, and scrolled in the drop target," but you need to be paying pretty close attention to notice that "Link" isn't mentioned, even assuming that you check the help before using the member in the first place! Similarly, the example code given on the help page for DoDragDrop does use DragDropEffects.All | DragDropEffects.Link in its call to DoDragDrop, but the use of the Link member there isn't called out or noted with a comment.

Due to its counter-intuitive nature, I would go so far as to call the omission of the DragDropEffects.Link bit from the DragDropEffects.All value non-standard... if the DragDropEffects enum wasn't a part of the standard .Net Framework library! :-) Perhaps there is a good historical (legacy support) reason for the exclusion, but if so, it isn't at all clear from just looking at the documentation.

Workaround: Crash running ATI video driver install

I'll first get right to the main point of this post; the full story behind how I encountered this issue is included at the end.

Issue and Workaround

When running the installer for the ATI Rage driver for Windows XP from the ATI site (from archive file wxp-ragexl-5-10-2600-6009.exe, unpacked by default to (C:\ATI\support\wxp-ragexl-5-10-2600-6009\setup.exe), an ATI logo and an InstallShield dialog with a progress meter appears. After the progress meter reaches 100%, the installer application crashed. Clicking the "Debug" button on the crash dialog reported an error in file _ins5176._mp.

Setup still crashed when I ran it with my virus scanner and other non-critical background processes temporarily disabled.

I was able to work around this issue an install the driver through the following procedure:

• Open Device Manager. (Start | Control Panel | System | Hardware tab | Device Manager button)
• In the Device Manager dialog, expand the Display Adapters tree item.
• Under Display Adapters, right-click on the ATI adapter item (this may vary; in my case, "XPERT 98 RXL AGP 2X") and select Properties from the context menu to open the Properties dialog.
• In the Properties dialog, on the Driver tab, click Update Driver to open the Hardware Update Wizard. In the Hardware Update Wizard dialog:
• In Step 1, the wizard asks "Can Windows connect to Windows Update to search for software?" Select the "No, not this time" radio button and click Next.
• In Step 2 ("What do you want the wizard to do?"), select the "Install from a list or specific location (Advanced)" radio button, click Next.
• In Step 3 ("Please choose your search and installation options"), select the Browse button.
• In the Browse For Folder dialog that appears, navigate to C:\ATI\support\wxp-ragexl-5-10-2600-6009\ATIDrive. Click OK. Back on the Hardware Update Wizard dialog, click Next.
• Proceed from that point to install the ATI drivers and finish the Hardware Update Wizard.

Background

The CPU case of my development machine at work had started making a moderate-volume loud humming/buzzing sound, coming from the power supply fan in the back of the case. (Normally the machine runs near-silently.) I opened up the case to see if I could fix the problem.

I did manage to get the fan fixed such that it stopped making noise, but when I came into work the next morning and powered on my machine, only one of my two monitors was working. The secondary monitor, which is connected to a cheap older PCI video card (an ATI Rage) that I had added to the machine to get dual monitor support, was not functioning; it just showed a blank screen, and the status light on the monitor showed yellow (sleep/inactive) instead of green (active). The ATI Rage display adapter was missing in both Device Manager and the Settings tab of the Display Properties dialog (where all available monitors are normally shown).

I think the cause of the problem was that I must have slightly jostled the PCI video card in its slot when I had the case open to fix the fan problem, such that the card was no longer tightly seated, and the computer could no longer "see" that the card was present.

I tried (with the computer powered off, of course) tightly reseating the video card in its slot; no luck, the computer still did see the video card.

At this point, I uninstalled the ATI driver, with the intention of updating it with the latest version. However, as it turns out, there was no newer version available (next time I'll check this before I uninstall!); further, when I tried to reinstall the driver, I encountered the setup.exe crash problem that I detailed at the top of this post, so I couldn't get the ATI driver to reinstall.

I then tried moving the card to a different PCI slot (which I have had some luck with in the past with a similar problem with a Soundblaster Live sound card not being detected by the computer in one of my home machines). This did get the card to show up in the Display Adapters section of Device Manager once again, but the card still refused to appear in the Display Properties dialog where multiple monitors are configured. I think the problem now was that the card was now running using the Microsoft-provided driver, which apparently did not include multiple monitor support for this particular model of video card.

Using the workaround I found, I did get the manage ATI drivers back in place. Even after a reboot, though, the ATI Rage card still wouldn't show up in Display Properties, and the monitor connected to the card continued to stubbornly refuse to activate or show anything.

Finally, I swapped the video card back to its original PCI slot, and everything started working again! It was a relief to get the second monitor back on; having enjoyed the luxury of working with dual monitors at work for a while now, I don't ever want to go back to doing development work on a single-monitor machine.

All in all this was not exactly the most productive hour or two that I've ever spent at the office! At least I did manage to find a workaround for that Windows XP ATI Rage display driver setup issue, which hopefully might help others out there experiencing the same issue.

Teaching a child to program in 2006

My son, Elijah, is now 16 months old. I have reflected once or twice on how I might go about introducing him to computer programming (in a few years, once he's older).

I myself first learned to program circa 1983, on an original IBM PC that my dad brought home from work. Like other PCs of the time, this machine did not have a hard disk; if booted with no floppy disk in the A: drive, a BASIC programming environment would come up. I remember writing programs that would do math problems, as well as some simple games, eventually including a Zork-like text-based adventure game.

It was a pretty nice "sandbox" environment to be able to experiment and learn in. The programming environment was easy to access (just turn on the machine!), and since the machine didn't even have a hard drive, and no floppy in the drive, I couldn't do anything to damage any of my dad's data.

So when Eli is ready to try out some programming for the first time, I've wondered, given today's much-changed environment from the one in which I learned to code back in the early 80s, how might I go about it? This afternoon, I came across a really nice series of blog posts by David Bau about how he went about first helping his (at the time) 6-year-old son learn to program.

David and his son Anthony start out writing just a text-based program, just like I used to do on the old IBM PC (and, as David writes, that he used to do on an old Atari machine). Despite the standard of today's kids' software of having rich visuals and sound, Anthony was pretty excited just to be able to create a text-based "guess the number" game (featuring a vampire!). And once Anthony was ready to want to add some simple graphics and sound to his game, David was able to figure out how to get it done with the help of some brief research via Google and some free libraries.

As a programmer and the parent of a young child, I found David's story to be an informative (as well as enjoyable and heartwarming) read. I now have a better idea of how I can go about first helping Eli learn to program when the time comes!

Ctrl+LeftArrow and Ctrl+RightArrow broken in VS 2005 Watch window

In the Visual Studio 2005 Watch window (where values of variables or expressions can be monitored during a debugging session), while editing a value in the Name field (where the variable/expression to be monitored is defined), support for the Ctrl+LeftArrow and Ctrl+RightArrow keyboard shortcuts isn't implemented properly.

In text-editing applications, the keyboard shortcuts Ctrl+RightArrow and Ctrl+LeftArrow commonly have the functionality of moving the caret (insertion point) to the beginning of the current word or the end of the next word. In the VS 2005 main code window, there is very good support for these keyboard shortcuts: in an identifier with several parts separated by period characters (such as System.Drawing.Rectangle.Empty), the insertion point is moved to before and after each period character on successive uses of the shortcut, making it easy to quickly navigate to either the beginning or the end of each component of the identifier. The insertion point also stops at other common code "punctuation", such as the [ and ] characters.

However, while editing a value in the Watch window, the Ctrl+LeftArrow and Ctrl+RightArrow shortcut behaviors follow a different set of rules. When these shortcuts are used in the Watch window, the insertion point bypasses most common code punctuation characters, and instead stops only at space characters. (A bit of additional testing I did shows that certain punctuation characters such as ? and ! are also treated as stopping points in the Watch window.)

Interestingly, this behavior appears to be a regression from Visual Studio 2003; in VS 2003, a quick test shows that when doing a Ctrl+LeftArrow / Ctrl+RightArrow in the Watch window, the caret does indeed treat a "." character as a stopping point. Possibly this is a result of a rewrite of the Watch window to implement one of the very nice new features introduced in VS 2005: Intellisense being enabled and usable when editing a value in the Watch window.