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.

Browser window relative screen position

This morning, I noticed an issue with a particular popup browser window that my development team's browser-based application opens. With the application running in an Internet Explorer instance in the right monitor on my dual-monitor dev system, when the popup window was opened, it appeared in the center of the left monitor.

I decided to change this behavior to have the new popup window appear on top of the parent window, to make the appearance of the new window more obvious. I knew that the location of the new window could be specified relative to the screen in parameter 3 of the Javascript window.open(URL, windowName, windowFeatures) call in IE using the top and left attributes, like:

window.open('http://localhost/', 'newWindow', 'top=200,left=300')

What I wanted to do was supply top and left attribute values based on an offset of the screen position of the parent browser window. However, it wasn't clear to me how to get the parent window position.

Google searches such as javascript window screen position weren't much help -- no obvious solutions to my question among the first several pages returned. Searching on "location" instead of "position" was even less help, since the results included a lot of keyword collisions with the location (URL) property of the window object.

Eventually I did come up with a quirksmode.org page with the answer I was looking for by searching on "screenX", the attribute used with window.open on Navigator/Mozilla/Firefox to specify the horizontal position of a new window. The solution: In IE, the screenLeft and screenTop properties give you the horizontal and vertical positions of the browser window relative to the screen, respectively. (screenX and screenY are apparentely the equivalent properties in Mozilla, although I haven't tested this myself.)

On a page with frames, self.screenLeft will return the horizontal position of the current frame relative to the screen, whereas self.screenleft will give you the position of the browser window relative to the screen.

Interestingly, support for the screenLeft and screenTop properties apparently was first introduced in Internet Explorer 5. (This is why my copy of The Flamingo was no help in finding the solution -- my old copy is only current through IE 4.) This seems to indicate that in IE 4, you could set the position of a window (either initially in the window.open() call, or later via the window.moveTo() method), but there was no way to get the position of the window!

In any case, I was able to solve my original problem of the IE popup window appearing in the wrong place by getting the screen coordinates of the parent window using calls to top.screenLeft and top.screenTop, then adding a delta to each of those values and using the adjusted values in the call to window.open().

Firefox Find Next/Prev shortcut keys

Firefox provides pretty nice hotkey support for the "Find Next" / "Find Previous" functionality of its incremental find/search feature. For the "Find Next" feature, several hotkeys are supported:

• Alt + n - Displayed on the Firefox Find Bar
• F3 - Standard in many Windows applications (Visual Studio, Word, notepad.exe, but not IE)
• Ctrl + g (Find again) - Displayed in the Firefox Edit menu; used by a few other apps

For "Find Previous", Alt + p, Shift + F3, and Ctrl + Shift + g are supported, which nicely mirror the "Find Next" shortcuts.

I like this broad hotkey support for these functions; I think the (arguable) inelegance of the redundant hotkeys is outweighted by the usability benefit of having whichever common Find Next hotkey combination that is intuitive to a particular user be supported.

The incremental find feature itself and its benefits have already been covered pretty well by Jeff Atwood -- head over there to read up if you aren't familiar with the feature.