Wednesday, November 15, 2006

Broken Word 2003 Shortcut for "Normal" View in Word 2007

At lunch today, I installed the Office 2007 release (obtained through my company's MSDN subscription), replacing my previous Office 2003 installation.

Per the online documentation and also a nice Jensen Harris (Microsoft) blog post, Office 2003 menu shortcut keys (e.g. Alt+F, S for File menu | Save) are supposed to work in Office 2007 as well.

When I fired up Word 2007 and opened a document, it put me in the "Print Layout" view. I'm accustomed to working in what was called "Normal" view in Word 2003, so I did Alt+V, N to try to switch to Normal view.

So far so good after the Alt+V -- Word 2007 even put up a nice little tooltip letting me know I had started typing a Word 2003 shortcut -- but subsequently pressing the N key had no effect.

I opened up the new "View" ribbon, and saw in the "Document Views" section that "Normal" was no longer present, but a new "Draft" view was available. I clicked that, and it put me in the equivalent of what "Normal" view was in Word 2003.

So "Normal" is apparently renamed to "Draft" in 2007... I switched back to "Print Layout" view (Alt+V, P did work), and then tried Alt+V, D to switch to "Draft" view -- it worked.

I fired up Word 2003 on my test machine to verify that Alt+V, D didn't work on that version. I expected it to have no effect... but Alt+V, D actually has a different function in Word 2003: hide/show the Document Map!

Consequently, the Alt+V, D shortcut for "hide/show Document Map" in Word 2003 is essentially broken in Word 2007 as well (since it now has a different function than before). I couldn't find any alternative "Alt+V" shortcut in Word 2007 for Document Map, although the "new" Alt+W (View ribbon), V, M shortcut does work for "hide/show Document Map" in Word 2007.

Monday, November 13, 2006

Fix: Firefox Downloads window does not appear

I recently had a problem where in Firefox, the Downloads window (the "Download Manager") wouldn't appear when I started to download a file. The Downloads window previously had been working fine.

The behavior I saw was that I would begin download of a file (typically something with a .zip extension), but the Downloads window would never appear, and I wouldn't get any notification that the download was in progress or that the download had finished.

I did verify that the "Show the Downloads window when downloading a file" checkbox in the Options dialog was checked. Checking and unchecking the checkbox and restarting Firefox didn't do the trick, either.

I also tried upgrading from Firefox 1.5 to 2.0, but the problem was still present after the upgrade.

A Google search didn't turn up any relevant information. On a suggestion from my brother Jeremy, I got more specific and searched the Mozilla Bugzilla database (the Firefox public bug-tracking system) for the issue, and came up with a similar issue, describing a problem where the Download Manager window did appear, but wouldn't show downloads in progress.

Ria Klaassen left a comment on that bug record with a suggestion to try deleting the downloads.rdf file in the Firefox profile folder, as it can sometimes get corrupted and cause problems.

I tried deleting my own downloads.rdf file and restarting Firefox, and the fix worked like a charm! My own Download Manager window is working perfectly once again. Thanks Ria!

Monday, October 30, 2006

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.)

Tuesday, October 24, 2006

"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.

Monday, October 23, 2006

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.