Writing VBA in Excel 2007 for use in Excel 2003

Question

Where I'm at the developers have been updated to Excel 2007, but most of the users haven't. I'm building a spreadsheet template (*.xlt) for a user that's gonna need some vba code included, and I'm wondering what issues I'm likely to run into building this in 2007 instead of 2003? I don't have access to a machine with Excel 2003 for testing, and I'm worried this particular project is headed for disaster.

Answer 1

You should be fine. As far as the VBA language is concerned, it hasn't been updated in years. VBA in 2007 is exactly the same as in 2003.

Answer 2

The VBA language hasn't changed, but there are additional objects in Office 2007 that are not in Office 2003. Naturally, this will cause a runtime error when you try to access these items in a 2003 environment. What's stopping you from setting about a virtual machine with Excel 2003 to develop under?

Answer 3

billb2112 is right. There are numerous changes to Excel 2007 over excel 2003 that are not backward compatible. While the language might not have changed, the objects have been updated. Some have had additional properties added, some work differently and some functions in Excel have changed.

You need to be very careful that what you code works in Excel 2003. I would suggest as billb2112 said that you get a virtual machine to not only test in but also to code in. I do all my Excel development for clients who only have 2003 in a 2003 machine. Note that if users have Excel 2002 or 2000 there are even more differences as you go back and you will simply get runtime errors on any code that these older versions don't support.

update unfortunately jeffs answer is not quite correct. while yes the vba language hasn't been updated it is not the same in 2007 as in 2003. as in 2003 its not the same as in 2002 etc. what has happened is extra and additional functions and arguments for functions have been added. for example there are more options in the FIND function in Excel in 2003 than in 2002. thus if you record a macro (the best way to find these problems) in 2003 and then run it in 2002 you will have run time errors relating to the new arguments that simply do not work in the 2002 VBA editor. following the same process for functions that have changed in excel 2007 and then going back to 2003 to test will help you locate these problems. some examples include conditional formatting, colours (themes) and numerous new spreadsheet functions. jon peltier has the best advice from that regard - develop in the oldest possible version that the client /user will use. Virtual PC 2007 is free to download and install. you will just need a licensed copy of XP/Vista and office to install to run in it.

Answer 4

Rather than depending on a probably incomplete list of objects and methods which have been added to Excel 2007's object library, the best (mmost relliable) practice is to always develop in the oldest version of Excel likely to be used to run the code.

Answer 5

i used to develop a lot of macros under 2003, what a POTA,, things like Find, Dir and some others are not available or something change. therefore some erros can be expected, i used to count from 65000 row to the first non empty row to count the rows to work on.... now more rows means more work to do

Answer 6

One difference I discovered is that a subroutine must have a different signature to be called from a menu (in Excel 2003) than when called from the ribbon (in Excel 2007). Whatsmore, Excel 2003 doesn't recognise IRibbonControl and throws compile errors.

To work toward cross-version compatability, I use a Conditional Compilation Argument and then check that in pre-processor macros.

e.g.

#If USINGRIBBON Then
    Public Sub CallFromRibbon(control As IRibbonControl)
#Else
    Public Sub CallFromRibbon()
#End If
    ' Code here
   End Sub

This does mean that you have to save one version of your add-in with the USINGRIBBON flag set to false (for Excel2003) and another with the USINGRIBBON flag set to true (for Excel2007), but this is far easier than maintaining two completely separate codebases.