Thursday, June 28, 2007

Howto: Disable auto-insertion of HTML end tags in Eclipse

In Eclipse (version 3.2.1), when editing an HTML page, Eclipse automatically completes HTML end tags that you are in the process of typing for you. For example, if you type:

<td></

Eclipse will immediately automatically add the rest of the tag -- in this case, td> -- for you, so that you end up with (with the part Eclipse added shown here in italics):

<td></td>

However, after years of typing HTML, I'm accustomed to quickly typing the entire HTML end tag myself without thinking about it. Over the last few days, since I've started to use Eclipse to edit HTML, I've frequently ended up with HTML like the following while I'm typing something out:

<td></td>td>

Eclipse adds the second td> automatically, but at the same time I'd typed it out myself without pausing to remember the fact that Eclipse is going to add it for me, and I'd end up with some broken HTML that I would have to either stop what I was doing to fix, or remember to go back and fix later. This got quite aggravating by the time it happened to me for about the 30th time. :-)

I started looking for a way to disable the end tag auto-insertion feature. I searched through the Window | Preferences settings in Eclipse, but couldn't find any setting that was responsible for the end tag auto-insertion. I also searched the Web with Google and Usenet with Google Groups, but couldn't come up with any relevant results even after trying several different variations on my search terms.

Finally, I posted my question to the Eclipse newsgroup eclipse.newcomer (free registration required to browse/post). Nitin Dahyabhai kindly responded and provided the solution:

The HTML end tag auto-insert feature is controlled by the "Smart Insert Mode" setting on the Eclipse Edit menu. You can uncheck the setting there to get Eclipse to stop automatically completing HTML end tags.

Having disabled the "Smart Insert Mode" setting, I'm now much happier while typing HTML into the Eclipse editor. Thanks, Nitin!

Wednesday, June 06, 2007

The Mystery of the Phantom "pbrush.exe" File

For a while now, I've known that you can launch the Paint image editor that is bundled with Windows by typing either one of mspaint or pbrush at the Start | Run dialog. I was recently using my PathFind utility (a which-like command-line utility that shows where a specified file is located on the path) to check on the locations of a few Windows programs, and I used it to find the locations of mspaint.exe and pbrush.exe on my Windows XP machine.

As expected, PathFind.exe showed that mspaint.exe was located at C:\Windows\system32. But when I had PathFind look for pbrush.exe, to my surprise, it reported that the file was not located anywhere on the path.

At this point, I got pretty curious about how running pbrush.exe from Start | Run was launching Paint when pbrush.exe apparently didn't exist on the path, and some brief searching on Google and Google Groups didn't reveal any answers, so I decided to don my Mark Russinovich-style Detective Hat and do some investigation to figure out just what was going on!

I tried using PathFind to search for "pbrush.*" to see if it was running from a filename with some other extension, such as pbrush.com. However, no file named pbrush with any extension existed on the path.

I still wasn't convinced that pbrush.exe didn't exist somewhere on the machine, so I hit Win+F to bring up Windows' built-in search, and searched my entire hard drive for files with "pbrush" in the name. However, even that search turned up 0 results. To all appearances, there simply was no file named pbrush present anywhere on the machine.

I did notice, by bringing up Task Manager, that the actual executable that was being launched was always mspaint.exe, even when I was entering pbrush in the Run dialog to launch the program. I was still curious, though, how running pbrush (which to all appearances did not exist) could cause the mspaint.exe file to be launched.

I started up Filemon and set up a filter to show only references to "pbrush", then launched pbrush.exe from Start | Run.

Interestingly, Filemon showed only a single "not found" error for pbrush.exe. Normally, Filemon will show a "not found" error for every directory in the path when an attempt is made to run a program with a filename that doesn't exist. So in this case, it appeared that Windows was looking in just the C: drive for pbrush.exe, and then doing "something else" which resulted in Paint being launched, before Windows went on to look for pbrush.exe on the path.

I then ran Regmon, again filtering on "pbrush", and ran pbrush.exe once again.

Aha! In line 6 of the Regmon output, I could see some kind of mapping from pbrush.exe to mspaint.exe. I figured that this must be the link between pbrush.exe (which I was running from the Run dialog) and mspaint.exe (the app that was actually getting launched) that I was looking for. So I decided to take a look at the HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths registry key.

I opened up Regedit and navigated to My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths.

At that location, I found a key for pbrush.exe, along with many other keys with names of .exe filenames, many of them familiar. By doing a bit of experimentation, I was able to conclude that the App Paths key acts as a sort of map that Windows uses to find the location of an executable file being run.

For most of the App Paths keys, the (Default) value for the key mapped to the full path to the executable of the same name; for example, on my machine, the Winword.exe key mapped to "C:\PROGRA~1\MICROS~2\OFFICE11\WINWORD.EXE", the actual location of the Microsoft Word executable. (As I discovered, this is why entering winword at the Start | Run dialog successfully launches Word even though the Office11 folder isn't on the path.) In the case of the pbrush.exe key, though, the mapping was to the location of mspaint.exe; thus, running pbrush resulted in mspaint.exe, the Paint program, being launched. Mystery solved!

From some newsgroup posts that I came across while researching this issue, apparently on Windows 9x series machines (e.g. Windows 98), a pbrush.exe file actually was included in the system32 directory that was just a stub which executed mspaint.exe. (In even older Windows versions, pbrush.exe was the 16-bit version of the Paint program; the 32-bit version, mspaint.exe, was apparently introduced with Windows 95.) For the 32-bit Windows NT series, an engineer at Microsoft must have decided to switch the pbrush command from working via the actual pbrush.exe stub file to taking advantage of the HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths registry key.

Friday, June 01, 2007

Tips from TweakUI

Earlier today I was using Microsoft’s TweakUI utility for Windows XP to make some changes to the settings on my new laptop, when I started going through the utility's "Tips" section. I picked up some interesting tricks that can be filed under "things I didn't know Windows could do"! I thought a few of the tips were interesting enough to be called out here, to spread the word about them.

Tip: You can simultaneously select multiple items (running applications) in the Windows Taskbar (at the bottom of the screen) by holding Ctrl and right-clicking them.

There are a couple of interesting uses for this trick:

  • Tile 2 or more specific applications
Holding Ctrl, select 2 or more applications on the Taskbar, then right-click one of them. On the context menu that appears, select Tile Horizontally or Tile Vertically to have the applications' windows be positioned side-by-side on the screen, filling all of the screen's entire viewable area.
  • Close 2 or more applications at once
As above, select the Taskbar buttons for 2 or more applications and right-click to bring up the context menu, and select Close to close all of the applications at once. I haven't played with this a lot yet, but this may be a faster method of closing many applications (right before shutting down a machine, for example) then individually right-clicking the Taskbar button for each app and selecting Close, or clicking the "x" button on each application's window.

Tip: In Internet Explorer's address bar, press Ctrl+Enter to have the browser automatically prepend "www." and append ".com" to the typed address.

I've been using this one for a while now (as I've mentioned previously), but it's enough of a time-saver that it's worth another mention. You can, for example, type google in the Internet Explorer address bar and press Ctrl+Enter to be taken directly to http://www.google.com, instead of having to type out www.google.com. (Credit to Jeremy for originally showing me this!)

This Ctrl+Enter shortcut works in Firefox as well!

Tip: In Internet Explorer, hold Shift while clicking the "Organize Favorites" menu pick to open the Favorites folder in Explorer.

This is a lot nicer than using IE's built-in Organize Favorites dialog -- which is kind of weak from a UI perspective -- which normally gets activated when the "Organize Favorites" menu item is picked.

Tip: In Internet Explorer, hold Shift while scrolling the mouse wheel to go Forward or Back.

You can also go forward/back without using the mouse by using Alt + Left Arrow (back) and Alt + Right Arrow (forward).

(Idle speculation: Are the functionality Alt + Left Arrow and Alt + Right Arrow shortcuts reversed for users of versions of Windows installed with a right-to-left language (as opposed to a left-to-right language like English)?)

You can hold the Ctrl key while scrolling the mouse wheel to increase or decrease the size of the text on the page.

These shortcuts all work in Firefox as well.

Press Win (Windows Key) + L to lock the computer.

This is useful to do when stepping away from your desk at work. (I'm not sure what, if anything, this shortcut does when Windows is configured not to prompt for credentials at startup.)

Thanks to the folks behind TweakUI at Microsoft for these great tips!