Compatibility issue in Office automation
-
Hi all, In my application of office automation, i add to my project object library(*.olb) of the version present on my system. But in this case i will only be able to run my application only for that version of office whose library i have included.(In my case, it is office 2000). in short, automation application developed using object library of office 2000 will run for office 2000 only which is actually not intended. How should i solve this compatibility issue? i may be asking a very naive Question. but i don't have any idea on this. Kindly Guide. Regards, Ankush Mehta
-
Hi all, In my application of office automation, i add to my project object library(*.olb) of the version present on my system. But in this case i will only be able to run my application only for that version of office whose library i have included.(In my case, it is office 2000). in short, automation application developed using object library of office 2000 will run for office 2000 only which is actually not intended. How should i solve this compatibility issue? i may be asking a very naive Question. but i don't have any idea on this. Kindly Guide. Regards, Ankush Mehta
Ankush Mehta wrote:
in short, automation application developed using object library of office 2000 will run for office 2000 only which is actually not intended.
What kind of problems are you experiencing? I have some word automation in my app it compiles against Word 9 (office 2000). The target PCs all have Office 2003. Everything works just fine. I did have to modify the way I was doing some stuff but other wise all works well.
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
-
Ankush Mehta wrote:
in short, automation application developed using object library of office 2000 will run for office 2000 only which is actually not intended.
What kind of problems are you experiencing? I have some word automation in my app it compiles against Word 9 (office 2000). The target PCs all have Office 2003. Everything works just fine. I did have to modify the way I was doing some stuff but other wise all works well.
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
Actually you used office 2000 type library.right!Now your application will work fine in all probability for all the later versions.However, try it on a machine with some prior office version(prior than office 2000) & it may fail. To play safe, it is suggested to use as earliest possible type library,probably office 95.However, there is an exception for access 97 which fails if run on access 2000 machine.Moreover, this early binding is not entirely reliable because some methods may be unavailable. The solution is late binding which although cost an overhead , it is for multiversion office automation.One hybrid binding(DISPID binding) is also used. i am still going through it to get more info. I would like anyone to help & shed some light on late binding & hybrid binding(DISPID binding).Looking forward to some ideas, Regards, Ankush Mehta
-
Actually you used office 2000 type library.right!Now your application will work fine in all probability for all the later versions.However, try it on a machine with some prior office version(prior than office 2000) & it may fail. To play safe, it is suggested to use as earliest possible type library,probably office 95.However, there is an exception for access 97 which fails if run on access 2000 machine.Moreover, this early binding is not entirely reliable because some methods may be unavailable. The solution is late binding which although cost an overhead , it is for multiversion office automation.One hybrid binding(DISPID binding) is also used. i am still going through it to get more info. I would like anyone to help & shed some light on late binding & hybrid binding(DISPID binding).Looking forward to some ideas, Regards, Ankush Mehta
I don’t have any means for testing. All of my computers are running 2000 or newer and I’m far too lazy to test it anyway. I do know you incur an initial performance hit with late binding; but after the object has been created the performance should be the same as early. I guess it comes down to how often are you creating the object (of access I guess in this case). If this is a database based app why not roll your own function that you’re relying on for access? What are you trying to accomplish?
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
-
Actually you used office 2000 type library.right!Now your application will work fine in all probability for all the later versions.However, try it on a machine with some prior office version(prior than office 2000) & it may fail. To play safe, it is suggested to use as earliest possible type library,probably office 95.However, there is an exception for access 97 which fails if run on access 2000 machine.Moreover, this early binding is not entirely reliable because some methods may be unavailable. The solution is late binding which although cost an overhead , it is for multiversion office automation.One hybrid binding(DISPID binding) is also used. i am still going through it to get more info. I would like anyone to help & shed some light on late binding & hybrid binding(DISPID binding).Looking forward to some ideas, Regards, Ankush Mehta
I assume your trying to use office automation to print an access table as posted here http://www.codeproject.com/script/comments/forums.asp?msg=1298682&forumid=1647#xx1298682xx[^]. Here is a good quick way to dump a recordset to a excel file, then call shellexecute to print that file. Delete it it after your done. CString str; str.Format("SELECT * INTO [Excel 8.0;DATABASE=%s].[%s] FROM [%s]", ExcelFile, Worksheet, table); Create an ADO Connection object to the database then call. pConn->Execute(str.AllocSysString(), NULL, adExecuteNoRecords);
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
-
I assume your trying to use office automation to print an access table as posted here http://www.codeproject.com/script/comments/forums.asp?msg=1298682&forumid=1647#xx1298682xx[^]. Here is a good quick way to dump a recordset to a excel file, then call shellexecute to print that file. Delete it it after your done. CString str; str.Format("SELECT * INTO [Excel 8.0;DATABASE=%s].[%s] FROM [%s]", ExcelFile, Worksheet, table); Create an ADO Connection object to the database then call. pConn->Execute(str.AllocSysString(), NULL, adExecuteNoRecords);
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
Well, let me explain the scenario. i wanted to create an application to print 1) Word Document 2) Text file 3) Excel Sheet 4) Access tables 5) Powerpoint Slide 6) Webpage 7) images(bmp,jpg,jpeg,gif) i initially started with using automation.As an afterthought, i found 1),2),3),7) can be printed using shell Execute. However, for 4),5),6) automation is the solution(that is what i think).Since my application is supposed to run on muliversion, Late binding must be used.As a matter of fact, i have even achieved printing using automation but i don't know if it is early binding or late binding and that is where i don't have any idea buddy...... Ankush Mehta