I recorded a macro in Excel 2007 which used TintAndShade and PatternTintAndShade. Unknown to me, these two functions are not supported in earlier Excel versions but thanks to StackOverflow, I got a workaround.
Or so I thought. There are (apparently) other functions not supported by 2003. I say "apparently" because I do not have access to Excel 2003 but a colleague has told me that the macro does not work. I started asking him to tell me where the macro fails and then solving that (and iterating) but this is a slow process.
Is there an easier way? Is there e.g. a list of new commands in Excel 2007 or a simple compatibility check?
As a coincidence, I came across this which might help: http://blogs.msdn.com/b/eric_carter/archive/2009/03/19/object-model-changes-for-developers-between-excel-2003-and-excel-2007.aspx
There is also a page on MSDN for Excel 2010 which although not directly relevant may also help: http://msdn.microsoft.com/en-us/library/ee836187.aspx
No, not really and I doubt that there is a fully compiled list of object changes.
The best solution would be to develop in 2003, there are very few objects in 2003 that aren't in later versions - filesearch is the only one I can think of off the top of my head. However there are loads of things in '07 that aren't available in earlier versions, particularly notable are the new functions included in '07.
Do you really have no way of developing in '03 can't you install it? There isn't really a foolproof way of ensuring that your workbook will work correctly in earlier versions of Excel unless it was developed in an earlier version (or it's really simple)
Related
I am converting a C# VSTO add-in to support multiple versions of Excel (2007, 2010, 2013). My current plan is to have 4 projects in the solution, the core functionality and the AddIn projects. My question is: is it possible to write the AddIn in such a way that it will work with all versions of Excel? If not, is there a common Excel object model that would work?
If there isn't a proscribed way to do it, I would extract out the functionality from the Excel object model into a set of classes/interfaces that could then pass through an adapter to get o the real objects, then have version specific projects that contain the adapters. However, this is a lot of work I'd like to avoid.
Thanks,
Erick
Look at these two options for office version independent addins:
NetOffice is a free wrapper that does something similar to what you described in your second paragraph
Addin express is a similar (but commercial) framework
For the second option the development looks something like this:
you select the lowest version of Office you wish to support
you write the code against the object model of that version
Even with that you will still find some differences in how different versions of Excel work. For example this is one change that needs to be considered.
I have a series of big excel files that work like a program, but I hate beeing tied up (stuck in VBA for excel 2003), so...
Whats the best way to implement a gui over a excel vba program (office 2003)? (are there any tools for that... I want to move away from the office suite, but still have it in the background)
Or what's the easiest alternative for migrating this code to a more open language.
Any ideias?
Have you looked at VSTO?
Resolver One is a Python spreadsheet system with strong support for importing from MS Excel. It's often used for the situation you describe.
Assume all traces of Office 2003 will be removed from the computer.
UPDATE:
I understand that I will still be able to use .xls files. I'm asking about automating Excel through the COM interop from outside Excel. When I add a reference to Excel to a VB project, it gives me a different version of the dll for different versions of Excel. If a program was compiled with a reference to Office 2003's dll, will it need to be recompiled for Office 2007? Will the code need to be updated to use the new dll?
You should have no problem with your code breaking. In my past experiences, even though I referenced old versions of the Interop Assemblies, the newer version of Excel has been able to handle the calls.
Now the same can't be said for trying to use a newer version of the Interop Assemblies with an older version of Excel...
It would be very surprising if there were many breaking changes between the versions. As I understand it, Microsoft has a number of customers using Office, and they wouldn't like a large number of breaking changes.
In my opinion, the above is actually a valid way of analyzing many questions of this type: "Could x possibly happen" is aproximately equivalent to "what would happen to Microsoft if they did x". If the answer is "something really bad would happen", then chances are that Microsoft figured that out ahead of time.
Of course, this doesn't work 100%. "Could Microsoft ever remove Web Application Projects from Visual Studio 2005" is a counterexample.
I need interop in my programs to automate several functions in Word and Outlook. Does anyone know a good place to start. My goal is to kick off a mail merge, create several different files and save them accordingly, then e-mail the different files to different people based upon who needs what. Any help learning how to use the interop properly would be greatly appreciated.
I am currently using Visual Studio 2008 and Office 2007 and use vb.net to write my programs.
A good way to get started is to use the macro editor to record the steps you are trying to perform. You can take the generated macro code and modify it for your purposes to suit. Click on the names of functions and variables of which you do not know the purpose and hit "F1" to get context specific help.
Add COM references to Outlook 12.0 Object library and Word 12.0 Object library.
This web page really helped kick me off: http://support.microsoft.com/kb/316383
Then, by recording macros you'll expose a lot of the stuff you'll likely want to work with. Word of warning, however, is that not everything exposed in VBA (macros) is accessible within VB .NET. I don't know why this is, but I've actually had to construct and execute a macro from VB.NET, written in VBA, within Excel to accomplish something that seemed ridiculously easy if it weren't for the strange disconnect between the two.
Some good info on Mail Merge: http://support.microsoft.com/kb/258512
Here's an article with some basic steps to get you up and connected with Outlook's Interop: http://support.microsoft.com/kb/313787
Hope this helps. I'll keep an eye out for questions from you here--I'd say I know quite a bit when it comes to interop.
You might want to start here: http://msdn.microsoft.com/en-us/office/bb266408.aspx.
There are a number of tutorials.
An application currently in development has the requirements for using MS Word to perform spell check on certain textareas within the application.
I currently have Office 2007 (which is the Office 12 com objects).
My question is, if I add in the Office 12 objects what will happen on boxes which have Office 2003? This is in regards to both other development boxes as well as the end users.
Am I correct in believing that the end result will be that the spell capabilities will not be available for those users? And if I used an Office 11 object would that mean that the users would be unable to perform the spellchecks if they have Office 07 installed?
We gave up on trying to use a dependency on Word, as both have differing versions installed or no Office installation at all! Instead opting for NetSpell.
I am guessing here, but if it is as you can't use the 2007 PIA (Primary Interop Assembly) with a 2003 installation, you could try accessing the PIA via reflection as I would guess the calls you want won't change between the two, and then it won't matter - you'll use whichever is installed. If you are installing the PIA as well, you can then either get the user to tell you which they have, or be a little more clever and just try 2007 and if it fails, try 2003.
Like I said, I'm guessing here but it might be worth a try.
EDIT: I found this link about Office PIA's. This refers to Excel but actually covers Office in general. I don't envy the task you have. Looks like you'll need to detect the PIA (which may or may not be installed) and act accordingly. Sounds like a job for reflection to me.
Newer versions of Office will maintain most if not all compatibility with older versions of COM objects. Meaning if you want to program against Office 2003 and 2007 you will need to use Office 11 COM objects as a dependency as they were the newest available when 2003 was released. As long as you verify that the methods you need exist both versions of COM objects you should have no problems as long as you use the older COM objects.
Unfortunately, although I have used this solution for my own work, I have not tested it with Spell Check. In the end make sure that you test your code with all version of Office that you wish to integrate with.
My gut reaction to this question, is to simply suggest you go another route. Try using a 3rd party spell-check control. They are relatively inexpensive (and you may find some free controls). At least that way you can control the version of the control included with your app and be able to rely on it's functionality. Quite frankly, I'm surprised this library isn't built into Windows already. Sure it's complicated with all of the languages Windows supports, but these days it's similar to copy/paste in terms of user expectations.
You can actually package both the office11 and office12 interops needed to work in BOTH versions. It takes some minor work but I managed to do it. I do a check in the registry to see which interop to call and then executes the spell checking with the correct version. It even goes so far as to check if you have Word installed and throws an error alert that you can't spell check without having Word. We're tied to using Word due to the medical dictionary that's tied into Office we're required to use.
Do a search on interop or Com wrappers and I think you'll find you can use both fairly easily.