This site will look better if you upgrade to a browser that supports web standards.
This page lists specific bugs in Excel 2004 that I've seen, or seen posted in the newsgroups or elsewhere. The list is not comprehensive.
This list is not endorsed by Microsoft. In most cases I don't know whether Microsoft considers them a bug. I don't have any idea when or even whether they will be fixed. Items marked (MSKB) are links to Microsoft Knowledge Base articles.
Some of these bugs appear to be fixed in SP1. Where I've noticed the change, I've indicated that in the individual items.
If therule is selected in the pane, pasting or entering a text date with a 2-digit year will bring up the error checking indicator and window, which allows the option of converting to a 4-digit non-text date.
Unfortunately the conversion does not occur if multiple cells are selected. The workaround using the error correction window is to convert them one at a time. A faster alternative would be to coerce the text dates by copying an empty cell, selecting the text dates, and choosing, selecting the and radio buttons. The result will be date serial numbers, so choose to choose your desired date format.
COUNTIF() only counts cells within the Used Range of a worksheet. This is usually not a problem, but if you're trying to count blank cells, e.g., by entering this in cell A1 of a blank sheet:
the function returns 1, not 50. If instead a value had been entered in B21, say, the function returns 20. This behavior is seen in XLv.X and WinXL02 as well. It was fixed in WinXL03.
Workaround: use SUMPRODUCT() instead:
which returns 20.
The LoadPicture function causes a compile error in Excel 2004 when applied to userforms or userform controls. The workaround is to load the Picture property at design time, using the VBE's .
Workaround: Fixed in SP-1.
Userforms in XL04 have a terrible problem with focus (which form/control is active or can be activated). The .Range.Copy bug is one example. Another example shown when one userform calls another. The second userform's window controls -e.g., the Close and Send to Dock buttons - are inactive (so if you don't have a close button on the userform itself, you have to force-quit XL). The calling form's window controls will show a color if moused over, but they aren't active. See an example.
Workaround: Update to SP-1. This is a partial fix only. The second userform now displays with the Close and Send to Dock buttons active. However, if the second userform is sent to the dock and then recovered (or if the second userform is called from the first another time), the Close and Send to Dock buttons are once again inactive. A second workaround will fix this: in the code that calls the second userform, hide the first useform before the second is displayed, then show the first again when focus returns. This however, prevents the information in the first userform from being displayed when the second userform is active.
Pressing the Tab or Enter keys doesn't change the focus on Userform controls (textboxes, buttons, etc.).
This is a problem only during development, but it can cause confusion. I've found that, at least intermittently, after a workbook or worksheet event macro has been run, deleting the macro removes it from the workbook or worksheet code module, but the event still fires and the macro still runs until the workbook is closed. This doesn't happen consistently, but I've seen it happen several times a day.
Workaround: Close and reopen the workbook.
I haven't been able to track this down entirely, but whenever procedures are deleted or renamed, there is a chance that remaining macros will fail with a "Compile Error: Only comments allowed after End Sub..."
Workaround: Copy the remaining macro(s) (only ) in to a new module, delete the old one, then close and reopen the workbook
If the code in a userform contains a Range.Copy command (e.g., Range("A1:A10").Copy), a Run-Time error 1004: Copy Method of Range Object failed error occurs. Since this doesn't happen when the same code is run from a regular code module (unless the procedure is called from a userform), it would appear to be an issue of the focus preventing the copy.
Workaround: Appears to be fixed with SP-1.
The xlPageBreak enumerated constant xlPageBreakNone is not defined in MacXL. This only becomes evident if Option Explicit is included in the module.
Workaround: Use zero instead.
Several people have reported that workbooks with pivot tables that were created or manipulated in WinXL2003 crash when the PT Wizard is invoked and the Back button clicked.
This appears to be fixed with SP-1.
Help states the first step in inserting a textbox is "On the Insert menu, click Text Box.". Unfortunately there is no Text Box item on the Insert menu (by default).
Workaround: Use the Textbox control on the Drawing Toolbar (). Alternatively, choose and drag the Textbox control to your menu.
This page last updated on
© Copyright 2001 - 2004 McGimpsey and Associates. Except where noted, all code on this site may be distributed under the Gnu GPL. Acknowledgement is appreciated.