Word 2004: Accented character in file name causes macro command to fail

Posted by Pierre Igot in: Macintosh
August 25th, 2004 • 4:42 am

This is exactly the kind of stuff that’s so infuriating about Microsoft. They finally introduce support for a long-awaited feature, such as long file names in Office 2004 — and in the process they manage to introduce new bugs that break the stuff that was working fine until now.

For many years now, I have been using the following macro command:

Sub autoOpen()
	myName = ActiveDocument.Name
	If ActiveDocument.PrintFractionalWidths = False Then
		ActiveDocument.PrintFractionalWidths = True
	End If
	setZoomTo175
	Windows(myName).Width = 900
	Windows(myName).Height = 950
	Options.AutoFormatAsYouTypeReplaceQuotes = False
End Sub

It’s a macro command that takes the name of the current document window, turns the “Fractional Widths” option on if it is not already on, changes the window’s zoom setting to 175% (using another subroutine), and then resizes the document window to 900×950 pixels, and turns off smart quotes (because I use Spell Catcher X for this).

Because the macro command is called autoOpen, it is a command that will be run automatically every time I open a document.

Prior to Word 2004, it had always worked fine, except for read-only documents. Then I installed Word 2004 and all of a sudden, I started getting error messages — not for every document I was opening, but often enough.

It didn’t take me long to figure out that the documents that were causing an error message were documents whose file name contained a non-ASCII character such as an accented “é” (very common in French, of course).

And it doesn’t take a Ph.D. in computer science to figure out that the bug is probably due to the introduction of support for long file names (longer than 31 characters, that is) in Word 2004. The VisualBasic component of Word 2004 was probably not properly updated to fully support the new file names. Indeed, when I click on the “Debug” button in the error alert that I get, it highlights the line:

	Windows(myName).Width = 900

in my macro command, which is the first line of code that actually tries to use the value of the myName variable.

Of course, Microsoft, being the US-centric company that it is, probably didn’t even bother to properly test Word 2004 and its VisualBasic language with file names containing non-ASCII characters.

I guess I am going to have to try and find a new work-around now. Grrr…


2 Responses to “Word 2004: Accented character in file name causes macro command to fail”

  1. Will Parker says:

    Pierre:

    Although as a (partially) disgruntled ex-employee, I have no particular love for the MacBU these days, I have to say that you’re expecting *way* too much of a group that has about 30 programmers and 40 testers, of whom exactly ONE programmer and five testers were directly responsible for the scripting features in Office 2004.

    “They finally introduce support for a long-awaited feature, such as long file names in Office 2004 — and in the process they manage to introduce new bugs that break the stuff that was working fine until now.”

    Introducing *any* new feature is going to also introduce bugs; the more areas affected by the new feature, the greater the potential for bugs, especially in a large software suite like Office.

    In this case, the bug that bit you was most likely missed because the testers who might have found it were working like slaves to test and debug the new Office AppleScript dictionaries.

    For what it’s worth, the AppleScript work was considered a top priority not because of its effect on end-users, but because the MacBU is moving toward highly automated testing, which in the end is *supposed* to allow testers more time to write test cases that will more thoroughly exercise the code in their areas. (Personally, I think it’s more likely to result in fewer testers…)

    While I agree that ‘your’ bug should have been caught, I have to disagree with your assertion that the root cause for the bug getting through was due to a US-centric corporate worldview.

    Microsoft’s corporate plans may indeed be US-centric, but that would have very little effect on any individual tester’s test planning, especially in the MacBU. Although they are a tiny group by Microsoft standards, they have programmers, testers and project managers from literally every continent except Antarctica, with native speakers of English, French, Spanish, Tagalog, Chinese (Mandarin and Cantonese), Hindi, Egyptian, Russian, Japanese, Portuguese, and several flavors of Arabic, and quite possibly several others that I’m not aware of.

    In addition, the MacBU’s ‘International’ test team *REQUIRED* every tester to do their testing using a different OS language configuration and keyboard every week, reinforcing the drive to make Office 2004’s Unicode support as good as possible.

    In the end, this bug comes down to the inattention of one or two testers who should have paid more attention to the International test team’s exhortations to include Unicode strings from all of the languages officially supported by Mac Office 2004 in their testing.

    By the way, make no mistake about it — *your* name is well-known to everyone in the MacBU, and a good deal of the bugs you find are entered into the bugbase, so some of your concerns do get addressed.

    However, I must tell you in all honesty, your habit of coating your bug reports with a generous layer of scorn and blame do not win friends among the very people most able to help you get those bugs fixed. I say this not to chastise you, but to suggest a better method of getting the bugs you find fixed.

    One change that might help you is to remember that the MacBU is largely ignored by, and therefore very different from, the rest of Microsoft. While the schemes of Gates and Ballmer can be seen in every single Windows-based product, the MacBU hasn’t been visited by either in living memory. Therefore, if you feel you must assign blame for a bug, aim low — think of who within the MacBU could have screwed up.

    (Missing functionality, on the other hand, could be due to the influence of other departments — the Longhorn team stepped down hard on at least one Office 2004 feature that would have upstaged their little party in 2006 or whenever.)

  2. Pierre Igot says:

    Will: Thanks for sharing. I still question Microsoft’s ability to meet the needs of international customers, however. If indeed the MacBU has people who are fluent in French, how is it possible that they still haven’t fixed the problem that causes Word’s spell checker to flag each and every occurrence of “etc.” in a French document as a spelling error? I am sorry, but there’s just no excuse for this.

    More generally, I don’t think that the MacBU is being very professional about their work if they let issues of alleged personal “scorn” interfere with it. As a long-time user of Word, I feel that I am entitled to express my exasperation when a feature or bug is, indeed, exasperating. Do I really have to censor myself and force myself to adopt a Zen-like attitude of profound detachment just so that MacBU developers will not be personally offended by what I write?

    As I have said countless times, saying that some feature in Word is “stupid” is not the same as saying that MacBU developers themselves are “stupid”. I don’t know anyone at the MacBU personally. I never mention any names or anything like that. The fact remains that no other piece of Mac OS software that I use (and I use quite a few) has so many frustrating and exasperating aspects — and that it’s been like that for the past 15 years or so. Saying so is not being “scornful”. It’s just being demanding as a user — and Mac users are significantly more demanding, especially when it comes to usability issues.

    As for the scripting bug mentioned here, I am not surprised to hear that AppleScript support was mostly a priority because of internal strategic issues. What I don’t understand is why they couldn’t use the existing VisualBasic architecture to do the automated testing. it’s not like cross-application issues (where AppleScript might be used to mimic interactions between Office and non-MS applications) are the most important aspect of Office use.

    I am also quite concerned about the move towards automated testing as such. I am afraid that automated testing will fail to mimic many real-world tasks and behaviours that are precisely areas where Word fails so miserably. For example, how would automated testing catch a bug such as the new one with word-based selection in Word 2004?

    Obviously Microsoft’s testing process is already not good enough to catch such bugs as it is. Moving towards more automated testing will just make things even worse.

Leave a Reply

Comments are closed.