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?
Related
I try to write an Excel VBA program that automatically creates a Powerpoint presentation. As far as I know, at first I should go to tools -> references and on the list of available references find and switch on the reference to the Powerpoint object library. However, on the list of available references I don't have the Powerpoint object library. What can I do to have it available? I have Powerpoint install and it works without problems.
Yes, I know I can use Powerpoint from Excel VBA macro without referencing to this object library (I can use late binding), but I would like to avoid that.
Edit:
Hm... just several minutes after posting this question I can see I have this reference on the list of available references. But I am quite sure that before I didn't have it. Is it possible that it became available now because just one minute ago I started PowerPoint?
The PowerPoint library file is msppt.olb.
If, for whatever reason it wasn't shown in this list, you could add it by running the regsvr32 command to register this particular file, or re-install PowerPoint - both should do the trick. Registering a COM file in this way puts a whole bunch of additions into the registry to let Windows know where the file is, how it can be accessed & what it's dependencies are.
In this case (i) I'm glad to hear you've already fixed the problem and (ii) sorry but it's unlikely - I'm guessing you just didn't spot it in the list the first time around (which is pretty easily done).
Is it possible to have modules be external to the actual Excel file and call the functions/subs within them externally?
My thinking is if there are multiple Excel files that use the same module, instead of updating each one of those files separately when I make a change, can I just update the one module stored on a server or something?
I have doing something like you describe for years. You can move your VBA code to a VB6 ActiveX dll, organize it into classes, and load that dll as a reference from Excel VBA.
This is a good way to reuse non-workbook specific code. For instance, I have code that queries a mainframe. I like to call it from Excel, but the details of the connection and how data is passed are contained in a dll that I can load from Excel, VB6, Word, .NET, wherever. I have a similar dll for reading data from AutoCAD drawings, one for interfacing with a product DB on a MySQL server, etc.
The code that remains in Excel tends to be simple formatting stuff. Say I return a variant array of strings (technically a COM SAFEARRAY) from some library that I wrote. I would then output it into Excel, maybe do a text-to-columns, and have a list of results returned to the user.
You can also pass and return more complex data structures. The beauty of VB6/COM Automation (and I didn't appreciate this until I learned to do it the harder way in VB.NET or C#) is that the data will flow in and out of your components seamlessly and all the necessary interfaces will be created for you.
The main change to your code will be replacing things like ThisWorkbook or ActiveSheet with explicit parameters like (Byval sht as Excel.Worksheet). These will be caught at compile time in VB6 (since it doesn't know what ThisWorkbook is), so you cannot overlook them; you are forced to pass an explicit reference.
I also notice that my code inside the dll becomes more paranoid if it receives a Worksheet or other Excel object as a parameter. In VBA you might have had more assurance that you were passing a good object since it was private to a given workbook. The dll does not know who is calling it, so I view the passed-in object with more suspicion (check if Nothing, sheet name, formatting clues to ensure I am using what I think I am using).
The only downside I see is that you will have to get a copy of Visual Basic 6.0. I bought mine in 1998. It is no longer available from Microsoft, but surely there is someone out there who will sell it to you. The latest service pack is SP6.
You will also have to become familiar with "regsvr32" and "regsvr32 /u" to deal with the "ActiveX can't create component" errors as you open your workbooks on various computers. I just publish my dlls to a mapped network drive and re-register them on the user's computers whenever there is a significant change. Obviously this is a intranet/single company solution. Publishing the updated versions is much more of a pain the farther you are distributed.
Not sure if this would satisfy your needs, but you could create your common module as an "add-in" and so install it so that all files that you open in the same instance of excel would have access to the add-in code.
It would not be my recommended way of doing it because I would be worried about suitable testing of all the excel files that use it, when you make a change, plus the added complexity of getting users to install your add-in (this may not be an issue for you). I have a "developersToolkit" module I use across 8 different Workbooks, but I import the module into each workbook so its stand alone and I can also test changes for compatibility with each of the 8 workbooks.
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.
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.
I am working on this project (an AddIn) for Excel 2007. It use aspose cells for this purpose as well as C#. I didn't write the code, but took over the project from somebody else. So I am still learning the excel portion as I know only C#. I did notice there is some code for creating workbook/worksheet. How do I know if its written in VB or VBA so that i can learn it?The file extensions are like .cls, .frm, .bas etc. I am using Visual Studio 2010.
Also the workbook/worksheets are password protected after creation.When I tried to change the password through VB/VBA code(whatever it is), it creates errors during build such as identifier expected, declaration expected etc.But when I undid the changes, all the errors disappeared. The only change I made was change the string that stored the password. (string "password" was changed to "password1") and suddenly other lines of code started getting errors.The errors are identifier expected, declaration expected etc. and that doesn't make sense to me. So i had to change the password through C# after it was password protected through VB/VBA.
Also, how do I debug VB/VBA code. I tried putting breakpoints through VS2010 , but it's not hitting them when I run the project.I am sure the worksheets are created using VB/VBA and so its getting inside those codes, but cant debug.
I open the AddIn using Visual Studio2010 and that's how work with the code,both C# and VB/VBA.I dont modify anything using Alt+F11.
.cls, .frm, and .bas are VBA files. I suggest you try debugging the code in Excel using the VBE (the Visual Studio equivillent for VBA). It's quite easy to debug in that enviornment.
The difference between VB (VB.Net) and VBA is quite big. That being said, VBA is a rather simple language, so if you have managed to grasp C#, I'm sure you can learn VBA with a little bit of reading and experimentation.
If you have a question about the actual code, I suggest you post it as a seperate question. :)
How do you get to the code? If through Excel by using the VBE, for instance by pressing Alt+F11, then it is VBA. If you open a project, then it is probably VB (VB6). Note that VB.NET use the .vb extension. Moreover, since VBA is a subset of VB then if you export VBA from a VBE project, the exported files default to their VB cousin's file extensions.
We really need to know how you get to the code.
Like I said, VBA (6.x) is a subset of VB6. The Excel part is just an object model that uses VBA. VB.NET is different and is not the case because the file extensions are wrong.
Therefore, concentrate on learning on VBA and Excel 2007 Object Model
MSDN Search for VBA at http://social.msdn.microsoft.com/Search/en-US?query=VBA&ac=8.
Creating VBA Macros to Manipulate Worksheets in Excel 2007 at http://msdn.microsoft.com/en-us/library/dd553655(v=office.12).aspx.
This article VBA Interoperability with Visual Studio Tools for the Office System (3.0) at http://msdn.microsoft.com/en-us/library/bb931201(v=office.12).aspx should help.