Access to an excel file via C++
Thanks for writing this examples, but I still don't understand how you get the info from ole/com viewer and how you understand what the required parameters are... Can you please explain this? I think if I understand how it works, I'll be able to do things on my own.
If you are going to use the IDispatch interfaces rather than generate headers using the midl compiler, I suggest you wrap the calls to Invoke and GetIDsOfNames into wrapper functions.
AutowrapNameInvoke is the most useful, in that it allows you to insert only the optional named arguments that you are interested in.
Autowrap.c
AutowrapNameInvoke is the most useful, in that it allows you to insert only the optional named arguments that you are interested in.
Autowrap.c
|
|
Thanks for trying to help the original poster and myself too CBurn! I see this is your first post here and a good one too!
I'm hoping actually someone else can step in here and help the original poster because I'm afraid I have to bow out. Fact is I'm stuck bad, and I simply can't justify spending more time on this at this point. Where I fell down and am stuck, is at the final stage necessary to have a complete working system, and that is the need to be able to set the Worksheet within an opened Workbook. I have successfully been able to open Excel using CoCreateInstance, set it to visible, and read/write data to whatever cell desired. But the last needed step is to be able to Select() the desired Worksheet within a Workbook, and if one can't do that, then all the rest is useless I'm afraid.
Also, my intent was to look at wrapping all the GetIDsOfNames()/Invoke() calls once I fully understood it. I expect if you wrote those wrappers or whever did so fully understands it.
Also, for me coding is a hobby as well as work, so I try to do everything myself rather than relying on code others have provided, although I do study other's code carefully to learn at times - as I'll likely study yours above. I have not done so yet at this point, and I'm wondering if it would succeed where mine is failing.
Actually, I even tried two radically different techniques for accomplishing this. Excel is a funny beast. I have been told that only IDispatch based calls work on Excel, but the fact is that isn't entirely true. It is possible to make direct VTable calls on some things. The big problem there is all of them don't succeed. Only some do. When I was having difficulty selecting the desired Worksheet using IDispatch I pulled out my direct access code, which relies on a typelib dumper program I wrote several years ago which dumps a type lib and creates C++ headers for whatever type lib I choose. I thought perhaps I could succeed there where I couldn't with IDispatch. However, I failed there too.
Here is a PowerBASIC program (I posted it earlier, but here I attached comments as to what is going on) that shows what I can't seem to achieve in C++ ...
This is the line I can't do to save my life ...
Object Call pWorkbook.Sheets(vVnt1).Select
In that line VARIANT vVnt1 is holding the BSTR for the sheet desired. For direct VTable access here are the two C++ interfaces auto generated by previously mentioned dump utility for the Sheets and the IWorksheets interfaces ...
Using direct VTable calls I can successfully obtain a pointer to either of these interfaces, which I believe are listed in the *.idl file a duals, but I can't successfully pull off the Select() calls that would cause my desired Worksheet to become the ActiveWorksheet. Lot f angst here!
Here is my direct vtable access code and the console output with it, that shows beyond any doubt that direct vtable access (early binding) is possible with Excel ...
(continued)
I'm hoping actually someone else can step in here and help the original poster because I'm afraid I have to bow out. Fact is I'm stuck bad, and I simply can't justify spending more time on this at this point. Where I fell down and am stuck, is at the final stage necessary to have a complete working system, and that is the need to be able to set the Worksheet within an opened Workbook. I have successfully been able to open Excel using CoCreateInstance, set it to visible, and read/write data to whatever cell desired. But the last needed step is to be able to Select() the desired Worksheet within a Workbook, and if one can't do that, then all the rest is useless I'm afraid.
Also, my intent was to look at wrapping all the GetIDsOfNames()/Invoke() calls once I fully understood it. I expect if you wrote those wrappers or whever did so fully understands it.
Also, for me coding is a hobby as well as work, so I try to do everything myself rather than relying on code others have provided, although I do study other's code carefully to learn at times - as I'll likely study yours above. I have not done so yet at this point, and I'm wondering if it would succeed where mine is failing.
Actually, I even tried two radically different techniques for accomplishing this. Excel is a funny beast. I have been told that only IDispatch based calls work on Excel, but the fact is that isn't entirely true. It is possible to make direct VTable calls on some things. The big problem there is all of them don't succeed. Only some do. When I was having difficulty selecting the desired Worksheet using IDispatch I pulled out my direct access code, which relies on a typelib dumper program I wrote several years ago which dumps a type lib and creates C++ headers for whatever type lib I choose. I thought perhaps I could succeed there where I couldn't with IDispatch. However, I failed there too.
Here is a PowerBASIC program (I posted it earlier, but here I attached comments as to what is going on) that shows what I can't seem to achieve in C++ ...
|
|
This is the line I can't do to save my life ...
Object Call pWorkbook.Sheets(vVnt1).Select
In that line VARIANT vVnt1 is holding the BSTR for the sheet desired. For direct VTable access here are the two C++ interfaces auto generated by previously mentioned dump utility for the Sheets and the IWorksheets interfaces ...
|
|
Using direct VTable calls I can successfully obtain a pointer to either of these interfaces, which I believe are listed in the *.idl file a duals, but I can't successfully pull off the Select() calls that would cause my desired Worksheet to become the ActiveWorksheet. Lot f angst here!
Here is my direct vtable access code and the console output with it, that shows beyond any doubt that direct vtable access (early binding) is possible with Excel ...
(continued)
|
|
In the include files above are IOffice.h and IExcel.h which were auto-generated by my TypeLib dumper code. I wouldn't be able to post them here because they are rather massive.
Just doing pure IDispatch using dispinterfaces, I fail too, and that is because I don't fully understand how to use the DISPPARAMS struct, and otherwise set up the IDispatch::Invoke() call to makle happen what I want, which is to Select() my desired Worksheet. Here's my failing code ...
CODE]
Output
CoCreateInstance(Excel) Succeeded!
pXLApp.Visible = true Succeeded!
_Application::Workbooks() Succeeded! - Got Workbooks**
Got ID For 'Open' In GetIDsOfNames()
Succeeded In pXLBooks->Open(Book1.xls)!
Got Sheets dispid!
dispid = 485
Failed To Get pXLSheets!
dispid (Value) = 6
vResult.bstrVal = Hello, World!
*/
[/CODE]
Just doing pure IDispatch using dispinterfaces, I fail too, and that is because I don't fully understand how to use the DISPPARAMS struct, and otherwise set up the IDispatch::Invoke() call to makle happen what I want, which is to Select() my desired Worksheet. Here's my failing code ...
CODE]
Output
CoCreateInstance(Excel) Succeeded!
pXLApp.Visible = true Succeeded!
_Application::Workbooks() Succeeded! - Got Workbooks**
Got ID For 'Open' In GetIDsOfNames()
Succeeded In pXLBooks->Open(Book1.xls)!
Got Sheets dispid!
dispid = 485
Failed To Get pXLSheets!
dispid (Value) = 6
vResult.bstrVal = Hello, World!
*/
[/CODE]
Last edited on
It won't fit! Posting it wouldn't do any good though it doesn't work anyway. Still stuck at not being able to execute a successful Select() call.
So the original poster has several options which I'll list...
1) Realize that he is attempting to accomplish one of the hardest thing one could ever attempt to do in C++ and give up;
2) Get someone else to provide wrapper code that works and instruct him how to use it. Perhaps UBurn's code above is it, or perhaps such code auto-generated by Microsoft's ATL is the answer;
3) Buy a software package/library for several hundred bucks that provides easy wrapper functionality. I believe the OP already has a free version of something like that;
4) Use another programming language with built in fuinctionality such as my PowerBASIC code shown above. That does it in all of about 20 lines of code. PowerBASIC's older versions (which would run the above supplied code) sell for about $90. The most recent versions are about $200;
For myself, I'll have to pick this up at some future date and try again maybe. Sorry I can't take any more time on this. I tried!
So the original poster has several options which I'll list...
1) Realize that he is attempting to accomplish one of the hardest thing one could ever attempt to do in C++ and give up;
2) Get someone else to provide wrapper code that works and instruct him how to use it. Perhaps UBurn's code above is it, or perhaps such code auto-generated by Microsoft's ATL is the answer;
3) Buy a software package/library for several hundred bucks that provides easy wrapper functionality. I believe the OP already has a free version of something like that;
4) Use another programming language with built in fuinctionality such as my PowerBASIC code shown above. That does it in all of about 20 lines of code. PowerBASIC's older versions (which would run the above supplied code) sell for about $90. The most recent versions are about $200;
For myself, I'll have to pick this up at some future date and try again maybe. Sorry I can't take any more time on this. I tried!
Freddie, about the select method on the sheet object, Excel is expecting a Boolean value in the Replace argument. You seem to be supplying a BSTR.
Try:
http://msdn.microsoft.com/en-us/library/ff841056(v=office.15).aspx
Using the wrapper functions I posted above, I rewrote your last code block as shown below. My call to the Select function returns S_OK.
exceltest.c
Try:
|
|
http://msdn.microsoft.com/en-us/library/ff841056(v=office.15).aspx
Using the wrapper functions I posted above, I rewrote your last code block as shown below. My call to the Select function returns S_OK.
exceltest.c
|
|
Last edited on
Hey CBurn! Thanks for helping with this! I got your program running with C++ in Mingw by just putting (void**) casts on the [out] parameters of the various QueryInterface() type calls.
But note that the issue is to feed a BSTR containing the desired sheet name within the workbook so that Excel makes that sheet the sheet from which it will read/write data. Its going to take feeding it a BSTR and not a bool to do that. Here is my modification of your code that just uses a Workbook which everyone should have, i.e., Book1.xls, which further has sheet1, sheet2, sheet3, etc. You'll need to fill in your BSTR with where you have it on your computer, but for me I put it in ...
C:\\Code\\CodeBlks\\XL_Dispatch\\Book1.xls
Your program opens Excel and makes it visible, loads the Book1.xls file, and sheet1 is selected. How to select sheet2?????
some of the formatting will likely not be right...
But note that the issue is to feed a BSTR containing the desired sheet name within the workbook so that Excel makes that sheet the sheet from which it will read/write data. Its going to take feeding it a BSTR and not a bool to do that. Here is my modification of your code that just uses a Workbook which everyone should have, i.e., Book1.xls, which further has sheet1, sheet2, sheet3, etc. You'll need to fill in your BSTR with where you have it on your computer, but for me I put it in ...
C:\\Code\\CodeBlks\\XL_Dispatch\\Book1.xls
Your program opens Excel and makes it visible, loads the Book1.xls file, and sheet1 is selected. How to select sheet2?????
some of the formatting will likely not be right...
|
|
I finally got mine crunched down to fit within 8192 bytes by removing useful whitespace and other useful stuff ...
|
|
Last edited on
There's some crazy stuff around the middle where I'm trying to set up the call to make "sheet2" active, and I'm just throwing everything at it I can think of to try and get it to work. One does that of course when one doesn't know what one is doing and one is desperate! :)
On the Book1.xls file I'm using sheet1 just has "Hello, World!" on it, which the program above satisfactorily outputs to the console, but on sheet2 in A1 I put something or other which I'm trying to get output. If you put something on sheet2 and get it output, then you know you've figured it out!!!
On the Book1.xls file I'm using sheet1 just has "Hello, World!" on it, which the program above satisfactorily outputs to the console, but on sheet2 in A1 I put something or other which I'm trying to get output. If you put something on sheet2 and get it output, then you know you've figured it out!!!
Last edited on
Freddie, if you want to use a BSTR to select a specific sheet, the Worksheets collection Item method will take either a BSTR (the name of the sheet) or a LONG (index of the sheet in the sheets collection). The Item method returns the requested Worksheet object, which also has a Select method.
Add the following to my post above:
Note: When you are invoking the Item method on a collection, you need to use AutowrapInvoke (not AutowrapNamedInvoke) and specify DISPATCH_PROPERTYGET as the type parameter. AutowrapNamedInvoke forces DISPATCH_METHOD to be passed to Invoke.
Add the following to my post above:
|
|
Note: When you are invoking the Item method on a collection, you need to use AutowrapInvoke (not AutowrapNamedInvoke) and specify DISPATCH_PROPERTYGET as the type parameter. AutowrapNamedInvoke forces DISPATCH_METHOD to be passed to Invoke.
Last edited on
CBurn, I think that might be it! I'm all coded out for today, but tomorrow I'll try it. Thanks!
Say CBurn, I don't think this is right here at the top of your AutowrapInvoke() function ...
The way I fixed it is the way you have it in AutowrapNamedInvoke(). Unless I'm not understanding it, my guess as to why it works OK with the error is that there is always some random bytes other than NULLs at dangling uninitialized pointer pDisp?
Fred
[/CODE]
|
|
The way I fixed it is the way you have it in AutowrapNamedInvoke(). Unless I'm not understanding it, my guess as to why it works OK with the error is that there is always some random bytes other than NULLs at dangling uninitialized pointer pDisp?
Fred
[/CODE]
I've been trying to follow the examples you posted and try to do stuff on my own, but no progress. :(
Freddie, in one of your posts, you've included "IOffice.h" and "IExcel.h". How did you generate those files?
I've tried the option in Ole/Com Viewer to SaveAs .h file but it didn't generate anything. The only thing that it generated was a file called EXCEL.IDL.
Alin
Freddie, in one of your posts, you've included "IOffice.h" and "IExcel.h". How did you generate those files?
I've tried the option in Ole/Com Viewer to SaveAs .h file but it didn't generate anything. The only thing that it generated was a file called EXCEL.IDL.
Alin
I haven't forgotten you Cojones, as this is still your thread. I've kind of taken it over I guess though. Really, we are both trying to figure this out. In spite of the fact I ought to be working on other things today, I'm going to work on this 'till I get it, hopefully soon.
But to answer your questions.
Various versions of Office or Excel deal with the type library in different ways. On this computer Excel is telling me its Excel 2010, but the actual exe is in a folder Office14, for whatever reason. If I open the version of OleView to which I have a shortcut on my Desktop (I may have various versions of that file too), and go to File >> View TypeLib, then navigate to my Office14 folder where Excel.exe is located, then select that file, OleView will run a lot of code to recreate the original Excel.idl file (IDL = Interface Definition Language). That is a good file for you to use as a start in understanding all this.
However, on other older versions of Excel, to get the *.idl file, you may need to select some other file such as an *.tlb, *.odl, or perhaps even something else.
But it sounds to me like you finally succeeded in getting a *.idl file. That is good. You are on the right track.
But to answer your questions.
Various versions of Office or Excel deal with the type library in different ways. On this computer Excel is telling me its Excel 2010, but the actual exe is in a folder Office14, for whatever reason. If I open the version of OleView to which I have a shortcut on my Desktop (I may have various versions of that file too), and go to File >> View TypeLib, then navigate to my Office14 folder where Excel.exe is located, then select that file, OleView will run a lot of code to recreate the original Excel.idl file (IDL = Interface Definition Language). That is a good file for you to use as a start in understanding all this.
However, on other older versions of Excel, to get the *.idl file, you may need to select some other file such as an *.tlb, *.odl, or perhaps even something else.
But it sounds to me like you finally succeeded in getting a *.idl file. That is good. You are on the right track.
I have the same version of Office installed. And yes, I've used the OleView from there and I have generated the excel.idl file. It seems there's all the stuff that goes around in excel in there.
I was asking about how you generated the excel.h files because I've seen the code there and it seems a little more self explanatory. An example below:
I was asking about how you generated the excel.h files because I've seen the code there and it seems a little more self explanatory. An example below:
hr=pWorkbooks->Open(strFileName,vNull,vNull,vNull,vNull,vNull,vNull,vNull,vNull,vNull,vNull,vNull,vNull,LOCALE_USER_DEFAULT,(IDispatch**)&pWorkBook);
Last edited on
Now, you can't include that *.idl code in your C++ code. It looks something like C or C++ but it isn't. The reason it isn't is because COM (Microsoft's Component Object Model) was designed to be language agnostic, and if they would have decided to use C or C++ for the language used to define COM interfaces, then COM would not have been useful, for example, to Visual Basic developers, who were really the main target of all this. Not the only target by any means - but the main one.
So the way it works is Idl is sort of a language agnostic way of defining interfaces, and Microsoft created a special compiler known as midl.exe whose main purpose was to create a binary type library file out the *.idl fed into it. That file generated from the *.idl is a *.tlb (type library) file. These can be stand alone or using the resource compiler they can be added to the exe.
The end result of all this is that Microsoft created a whole massive Api for reading type libraries and there is a whole lot of functions, interfaces, and complexity in that. However, it allowed non C or C++ languages to be able understand the interfaces if they can read this type library.
Now, what C or C++ coders want is simply a *.h file that allows them access to the interface definitions so that they can call the methods of the object.
Those two files you mentioned are just that, and I spent many months writing my own code using the type library Apis to generate them from a type library. Actually, my intent was to create something useful to me as a C++ coder like I have in my PowerBASIC coding where this is all very, very, easy. What happens there in PowerBASIC is there is a utility called their 'COM Browser'. Its a GUI utility that lists in a massive listview control all the type libraries on a system. One simply double clicks on a library - such as the Excel library, and the utility auto-generates the massive include file that PowerBASIC uses, and by including that in one's program, one has access to all the interfaces and methods. Its a lot like OleView, except that instead of producing the *.idl file, it produces PowerBASIC headers.
Now, if you have Visual Studio, Microsoft included a utility to do that for C++ coders as part of its ATL modules. I forget the name of it, but that was what kbw was alluding to when he said there was an easy way to do this. For my part though, I never liked it or ATL. That's why my intent was to produce my own utility to generate C or C++ headers exactly like I like to see from my PowerBASIC work.
So the way it works is Idl is sort of a language agnostic way of defining interfaces, and Microsoft created a special compiler known as midl.exe whose main purpose was to create a binary type library file out the *.idl fed into it. That file generated from the *.idl is a *.tlb (type library) file. These can be stand alone or using the resource compiler they can be added to the exe.
The end result of all this is that Microsoft created a whole massive Api for reading type libraries and there is a whole lot of functions, interfaces, and complexity in that. However, it allowed non C or C++ languages to be able understand the interfaces if they can read this type library.
Now, what C or C++ coders want is simply a *.h file that allows them access to the interface definitions so that they can call the methods of the object.
Those two files you mentioned are just that, and I spent many months writing my own code using the type library Apis to generate them from a type library. Actually, my intent was to create something useful to me as a C++ coder like I have in my PowerBASIC coding where this is all very, very, easy. What happens there in PowerBASIC is there is a utility called their 'COM Browser'. Its a GUI utility that lists in a massive listview control all the type libraries on a system. One simply double clicks on a library - such as the Excel library, and the utility auto-generates the massive include file that PowerBASIC uses, and by including that in one's program, one has access to all the interfaces and methods. Its a lot like OleView, except that instead of producing the *.idl file, it produces PowerBASIC headers.
Now, if you have Visual Studio, Microsoft included a utility to do that for C++ coders as part of its ATL modules. I forget the name of it, but that was what kbw was alluding to when he said there was an easy way to do this. For my part though, I never liked it or ATL. That's why my intent was to produce my own utility to generate C or C++ headers exactly like I like to see from my PowerBASIC work.
I'll give you an example of what a PowerBASIC include looks like generated by their COM Browser. Because Excel has massive functionality and a lot of interfaces and methods, the whole file is about 700K. But it starts out like so ...
And here would be what an interface definition looks like, and it is such that allows one to call into it ...
Note the Select member above. That's what I'm fighting with!!!
Anyway, there is a lot more to all this. See those numbers above in angle brackets? They are dispatch IDs. Very important!
But backing up, those files you asked about were generated by code I have that attempts to produce for me (C++ headers) what the PowerBASIC COM Browser above is doing for PowerBASIC.
However, there's a whole lot more to all this, believe me.
Taking a very high level view, there are two general ways of using COM objects. One way - and the best way - and the easiest way - for C++ coders, or PowerBASIC coders, is direct VTable access. This is extremely fast. Its as fast as a function call. With direct VTable access, the object returns a pointer to a VTable - that is what an interface is, it is a block of memory containing function pointers. And the client can make direct method calls off that interface pointer.
But not all languages are able to do this. Things like VB Script, Jasva Script, so on and so forth, can't handle function pointer calls several levels of indirection removed. So what Microsoft did was create a whole 'nother Api for such languages lacking horsepower. It was called 'OLE Automation' and worked off something they cooked up called IDispatch.
The way IDispatch works is that there are only 7 methods in the interface. But two are very important. ::GetIDsOfNames returns the dispatch id (remember those) of a string name passed into it, which represents the name of the method one wants tro call. That is the dispatch ids you see in the PowerBASIC include above(they are also seen in hex in the *.idl). Then, once you have that dispid, the ::Invoke method of IDispatch calls the method within the object that you want to use. Invoke is incredibly ugly, as you can see. Just read up on IDispatch::Invoke in MSDN, and try to track down all the related structs such as DISPPARAMS, etc. Last word in mean!
Well, if its so mean and I'm using a powerful language such as C++ why not use direct VTable access instead of IDispatch which is so nasty? Well, the sorry fact is that Microsoft botched up the Excel COM infrastructure code and only IDispatch access works completely.
The whole reason I was trying VTable access was that I have full mastery of that whereas I'm weak at IDispatch. I hate it. And some of the direct VTable calls work and some don't. But if I were you I'd forget it because I don't think we can get it working with direct VTable access.
Hope this helps!
|
|
' Library Name: Excel
' Library File: C:\Program Files\Microsoft Office\Office12\EXCEL.EXE
' Description : Microsoft Excel 12.0 Object Library
' Help File : C:\Program Files\Microsoft Office\Office12\VBAXL10.CHM
' Help Context : 0
' GUID : {00020813-0000-0000-C000-000000000046}
' LCID : 0
' Version : 1.6
' Version Dependent ProgIDs
$PROGID_Excel_Application12 = "Excel.Application.12"
$PROGID_Excel_Chart8 = "Excel.Chart.8"
$PROGID_Excel_Worksheet8 = "Excel.Sheet.8"
' Version Independent ProgIDs
$PROGID_Excel_Application = "Excel.Application"
$PROGID_Excel_Chart = "Excel.Chart"
$PROGID_Excel_Worksheet = "Excel.Sheet" |
And here would be what an interface definition looks like, and it is such that allows one to call into it ...
|
|
Note the Select member above. That's what I'm fighting with!!!
Anyway, there is a lot more to all this. See those numbers above in angle brackets? They are dispatch IDs. Very important!
But backing up, those files you asked about were generated by code I have that attempts to produce for me (C++ headers) what the PowerBASIC COM Browser above is doing for PowerBASIC.
However, there's a whole lot more to all this, believe me.
Taking a very high level view, there are two general ways of using COM objects. One way - and the best way - and the easiest way - for C++ coders, or PowerBASIC coders, is direct VTable access. This is extremely fast. Its as fast as a function call. With direct VTable access, the object returns a pointer to a VTable - that is what an interface is, it is a block of memory containing function pointers. And the client can make direct method calls off that interface pointer.
But not all languages are able to do this. Things like VB Script, Jasva Script, so on and so forth, can't handle function pointer calls several levels of indirection removed. So what Microsoft did was create a whole 'nother Api for such languages lacking horsepower. It was called 'OLE Automation' and worked off something they cooked up called IDispatch.
The way IDispatch works is that there are only 7 methods in the interface. But two are very important. ::GetIDsOfNames returns the dispatch id (remember those) of a string name passed into it, which represents the name of the method one wants tro call. That is the dispatch ids you see in the PowerBASIC include above(they are also seen in hex in the *.idl). Then, once you have that dispid, the ::Invoke method of IDispatch calls the method within the object that you want to use. Invoke is incredibly ugly, as you can see. Just read up on IDispatch::Invoke in MSDN, and try to track down all the related structs such as DISPPARAMS, etc. Last word in mean!
Well, if its so mean and I'm using a powerful language such as C++ why not use direct VTable access instead of IDispatch which is so nasty? Well, the sorry fact is that Microsoft botched up the Excel COM infrastructure code and only IDispatch access works completely.
The whole reason I was trying VTable access was that I have full mastery of that whereas I'm weak at IDispatch. I hate it. And some of the direct VTable calls work and some don't. But if I were you I'd forget it because I don't think we can get it working with direct VTable access.
Hope this helps!
I got CBurn11's code working with his update Cojones!!! I want to thank him for that. If there is a new Member of the Month here he gets my vote!
So we're in! Now that we can programatically select the Worksheet within the Workbook we want, there's no stoping us.
The only thing that's bad for me is I don't understand CBurn11's code. I need to disect it to death to figure out how it works. But it does work. Here is the code of his that works with only one correction and some reformatting to suite my formatting tastes (sorry CBurn!). It works on basically the default workbook Excel creates, i.e., Book1.xls. And in that workbook are Sheets Sheet12, Sheet2, and Sheet3. You need to fix the path to wherever you have something like that. First I'll post CBurn's original C code version, then one I took the liberty of converting to C++ calls
So we're in! Now that we can programatically select the Worksheet within the Workbook we want, there's no stoping us.
The only thing that's bad for me is I don't understand CBurn11's code. I need to disect it to death to figure out how it works. But it does work. Here is the code of his that works with only one correction and some reformatting to suite my formatting tastes (sorry CBurn!). It works on basically the default workbook Excel creates, i.e., Book1.xls. And in that workbook are Sheets Sheet12, Sheet2, and Sheet3. You need to fix the path to wherever you have something like that. First I'll post CBurn's original C code version, then one I took the liberty of converting to C++ calls
|
|
And here is the above code converted to C++ isms. Hope you don't mind CBurn11!!! Personally, I have nothing whatsoever against C code. I do it mostly myself. I'm actually stuck in some kind of strange reality between the two. I only compile as C++ but use absolutely nothing in the C++ Std. Library. I have my own String class, my own template based multi-dimensional array implementation, ODBC class, etc. But that's another story. But here's the above in C++
|
|