By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,750 Members | 1,471 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,750 IT Pros & Developers. It's quick & easy.

Office Backward Compatibility

P: n/a
I've created some code, manipulating an Excel application.
Unfortunately this does not work on systems with Other Office distros
than Office XP.

Is there something I can do to ensure compatibility?Some header or
Define

There was an example in MSDN web Doc, but those guys in M$ seem to
have a very good relationship with entropia.... :evil:

Nov 16 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
pontifikas,

There are a number of options you have here, none of them too appealing
(IMO).

The first would be to set references to each version of office in your
app. Then, you have to determine which version is installed, and make the
call to the appropriate version from your code. This will require a good
number of switch statements, and is very unwieldy. Of course, you could
create wrappers which expose the APIs that you wish, but given the size of
the Excel API, it's impractical.

I'm not sure about this one, but you could try and add a reference to
the lowest version of Excel you will support, and only make calls to the
functions on that version you know are supported. The new implementations
should support the old interfaces.

I think the best solution would be to use VB for all of your calls to
Excel. Basically, you can create an instance of Excel and assign it to a
reference of type object. Once you do that, you can make late bound calls
to the object. This would allow you to assign any instance to the
reference, and have the calls succeed, as long as all the calls have the
same naming/calling convention across versions.

Of course, the last option has a perf hit, but if you have to maintain
reams of Excel code across versions, then it's the best way to go. You can
always place all of the other Excel calls in types in another assembly, and
then reference it from C#. You could do this in C#, but it would require a
number of reflection calls which is also unwieldy.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"pontifikas" <cs******@scylla.cs.uoi-dot-gr.no-spam.invalid> wrote in
message news:41**********@Usenet.com...
I've created some code, manipulating an Excel application.
Unfortunately this does not work on systems with Other Office distros
than Office XP.

Is there something I can do to ensure compatibility?Some header or
Define

There was an example in MSDN web Doc, but those guys in M$ seem to
have a very good relationship with entropia.... :evil:

Nov 16 '05 #2

P: n/a
Thanks mate, but I dont want to mix VB to my code and I dont know
VB....
:?

But I cannot find the libraries nessesary for each Office distro and
as I said the MS documentation is a mess.

In my code I use
Microsoft.Office.Interop.Excel

I thought "Interop" means "Interoperability".It appears it doesnt...

Can anyone provide me a link with an example, where according to the
office distro in use, the appropriate code gets excecuted?

Nov 16 '05 #3

P: n/a
I tried to use late binding, using the example found here:
http://support.microsoft.com/kb/q302902/#5

But it appears that the "Add" method is buggy for it throws an
exception saying that the library I use is old.

As I said I have office 2000 and 97 and I want to create an automation
client.
Has anyone used Late Binding for this type of situation?

Do you think that including the office 97 dll and using [DllImport] to
call the corresponding "add" function whould do the tric?

Thanks in advance

*-----------------------*
Posted at:
www.GroupSrv.com
*-----------------------*
Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.