I have been involved in writing an excel workbook for data analysis in Excel 2010. However I recently found out that some of the machines on which this document needs to be used run Excel 2003. I'm aware of the compatibility issues with saving to .xls format see here, but haven't been able to find a good summary of changes to the VBA code, specifically how to change from 2010 to 2003 (rather than the other way).
I do have access to a computer with Excel 2002 for testing, but it's very slow, in a room at the opposite end of the building, and has no internet access. So to avoid having to go back and forth to look up issues as they arise, I was hoping for some sort of list or summary that I could look through to identify issues before they arise.
I am aware that a similar question has been asked about 2007-2003 compatibility:
However all the answers simply suggest the use of a virtual machine. I do not have permission to install programs on my work computer (I'm not primarily employed for programming/IT), nor do I have Office on my home computer, or access to a licence.
The charting object model was substantially changed in Excel 2007, and then omitted from the macro recorder. Excel 2010 restored the macro recorder for charts, but you'll find the recorded code likely won't run on Excel 2003.
Tables aren't supported in Excel 2003. Use dynamic named ranges instead if you want a range object to grow automatically with the amount of data.
Excel 2003 uses command bars rather than the ribbon. If you put icons on the ribbon, you'll need to approach it differently for Excel 2003.
The Analysis ToolPak is an optional install in Excel 2003. If you use functions from it in your code, you'll need to make sure that it is installed and enabled.
If you save files in code, make sure that you use the FileFormat parameter (specifying the extension is not sufficient). Also make sure that you use integers rather than Enums for the FileFormat parameter (e.g. 51 instead of xlWorkbookDefault) because Excel 2003 won't recognize the newer Enums.
Related
I'm currently trying to implement something in the office that runs from powerpoint and goes into excel, but to do so I need to add a reference to Excel (unless I do late binding, which I don't want to do.) This is the code that will be adding the GUID reference:
'Activate Excel Library (version 2.0)
Application.VBE.ActiveVBProject.References.AddFromGuid _
GUID:="{00020813-0000-0000-C000-000000000046}", _
Major:=0, Minor:=0
The issue here is that not everyone in the office has the same version of Excel. I need to be able to add a reference to anyone's Excel. Is there a list out there somewhere of all possible GUIDs since like office 2003?
Or maybe there's a different way I'm not thinking of to do this?
I used Excel 2016 to create an Excel table with VBA program to generate a Word Document report automatically. The macro generates a compile error when used on Excel 2013 with older Office Library.
I tried the following without success:
using an older version of Excel to save the macro (no improvement).
changing the code (e.g: Word.Application -> Object) as proposed on other threads. The main problem is that the program is ~2000 lines long and when I fix something, another compile error arise a few lines later. Plus, the formatting in the Word document is altered.
updating to Office 2016 is not a solution either for various compatibility reasons with other programs.
The only remaining solution I can see is to export the Microsoft Office 16.0 Office Library and the Microsoft Excel 16.0 Library to the computers running Excel 2013 and adding them to the VBA References.
I cannot locate these 2 Libraries. The path is shown in the Tools->References window but is cut because the window is too short (and of course not possible to resize).
What is the path and file name to the 2 libraries?
Do you think that this solution will work and if not, do you know a better one or a workaround?
As I have to give up my old laptop and migrate with all my important stuff to a newer and more powerful machine, I now want to transfer all my MS Word (MS Word 2010) macros and user forms to the new machine (also MS Word 2010).
In the VBA editor, there is an option to export individual (!) modules and user forms (--> File --> Export file). But this seems to work only for one item a time. I have dozens of items and want to export all of them at once. Is there a way to do this?
(I have read How To Deploy Word 2010 Macros To Others?, but this does not help here.)
Update: My question was based on the assumption that transferring normal.dotm to the new system would not transfer the macros and user forms too. I now see that this assumption was wrong: indeed, transferring normal.dotm to the new system (in Windows 7, this would usually be in c:\users[user name]\AppData\Roaming\Microsoft\Templates), seems to include VBA modules and user forms. However, there might be situations when one wants to export multiple modules without giving away an entire normal.dotm, e.g. when one wants to provide a friend with some macros etc. So the question is anyway of interest.
What is the best way to avoid duplicating code when working in VBA?
I'm used to languages where I can just add an import statement and get access to all a class's public properties and functions, so I can just create a utility class with some common functions and have access to that in any project I choose to import it to. Any time I want to update one of those functions, one edit is all it takes to get it working across all projects.
Is there any good way to replicate this functionality in VBA?
What follows focuses on Excel but I am pretty sure the same would apply to any Office products.
The easy way is to save your reusable code as an addin (*.xla for Excel 2003, *.xlam for Excel 2007+). You then add the addin to Excel and all the spreadsheets you open will have access to the custom functions you have in your addin. If you add specific VBA code to a spreadsheet, you can add a reference to your addin and your VBA code will have access to all the public sub, function and classes of your addin.
In my organisation, we use 3 home made addins - they are stored in C:\Program Files\OrganisationName. And everybody has access to them. When an update is made, we only need to copy the new version to everybody's hard drive and restart Excel and they have the new version.
The addins contain utilities functions such as functions to:
read data from / write data to spreadsheets / files / databases.
usual data manipulation such as removing duplicates from a list
advanced statistical functions
etc.
A few drawbacks:
If you have several instances of Excel open, only one can update the addin, the other instances are in read-only mode
If Excel crashes, the auto recovery mode generally does not save the changes you made on your addin (TBC on newer versions) - there are a few tools to auto save regularly
An alternative is to develop xlls or COM libraries in VB or C# for example, but this is something I have not tried.
There are plenty of tutorials online if you need a more detailed procedure.
We have built an Excel 2003 template that asks the user to select an XML file which is then imported into an XML Map and used to populate a worksheet.
Unfortunately it turns out that the users have Excel Standard Edition, which does not include the XML import functionality - namely the Workbook.XmlImport function.
Users are able to open the XML file via File -> Open etc, however this opens it up as a new workbook.
Does anyone know of a way to get around this? How can we get the XML data to populate the XML Map when the users have Excel 2003 Standard Edition?
Quick workaround:
Let them select the file to open
open that file into a new workbook using vba,
copy the contents of the new worksheet (or read it all in to vba recordsets to parse)
paste it back into your active worksheet (maybe after you've done stuff to it in VBA)
close the xml worksheet, not saving any changes.
That would get around it, but it won't be quite as flexible. Depends how much you need to do with it.
Any help?
The best course may be to buy a used version of 2003 Professional. You can get one for about $50. If you have a ton of users, this obviously doesn't scale. If you have four users, this would be a $200 fix to your problem.
If you're on the verge of upgrading, you might accelerate that process and make sure the 2007 flavor has XML support. I want to say that all of 2007 has XML, but definitely investigate it before you take my word.
Option 3 involves a lot of time and code. You can write VBA to import and refresh XML (or CSV or something else). Obviously you'd have to weigh the cost of coding to finding and buying enough used licenses.