problem importing a com file in c++
-
i did that but it gives me the following errors Error 1 error C2059: syntax error : '(' d:\hitech work\jniwork\testingrexx\testingrexx\debug\msvbvm60.tlh 483 TestingRexX Error 2 error C2059: syntax error : '(' d:\hitech work\jniwork\testingrexx\testingrexx\debug\msvbvm60.tlh 925 TestingRexX Error 3 error C2059: syntax error : '<L_TYPE_raw>' d:\hitech work\jniwork\testingrexx\testingrexx\debug\msado27.tlh 2380 TestingRexX Error 4 error C2238: unexpected token(s) preceding ';' d:\hitech work\jniwork\testingrexx\testingrexx\debug\msado27.tlh 2380 TestingRexX
Human knowledge belongs to the world.
Well - that tells you where the CollectionPtr comes from - it's a VB thing. OK, in that case you can explicitly define CollectionPtr yourself (look at how it's defined in the msvbvm60.tlh file) and remove the auto_search from the #import statement.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Well - that tells you where the CollectionPtr comes from - it's a VB thing. OK, in that case you can explicitly define CollectionPtr yourself (look at how it's defined in the msvbvm60.tlh file) and remove the auto_search from the #import statement.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
please my friend , can you explain in more detail i am not c++ savvy be patient please with me i searched that file but i didn't find _CollectionPtr i found that struct __declspec(uuid("a4c46780-499f-101b-bb78-00aa00383cbb")) _Collection : IDispatch { // // Wrapper methods for error-handling // _variant_t Item ( VARIANT * Index ); HRESULT Add ( VARIANT * Item, VARIANT * Key = &vtMissing, VARIANT * Before = &vtMissing, VARIANT * After = &vtMissing ); long Count ( ); HRESULT Remove ( VARIANT * Index ); IUnknownPtr _NewEnum ( ); // // Raw methods provided by interface // virtual HRESULT __stdcall raw_Item ( /*[in]*/ VARIANT * Index, /*[out,retval]*/ VARIANT * pvarRet ) = 0; virtual HRESULT __stdcall raw_Add ( /*[in]*/ VARIANT * Item, /*[in]*/ VARIANT * Key = &vtMissing, /*[in]*/ VARIANT * Before = &vtMissing, /*[in]*/ VARIANT * After = &vtMissing ) = 0; virtual HRESULT __stdcall raw_Count ( /*[out,retval]*/ long * pi4 ) = 0; virtual HRESULT __stdcall raw_Remove ( /*[in]*/ VARIANT * Index ) = 0; virtual HRESULT __stdcall raw__NewEnum ( /*[out,retval]*/ IUnknown * * ppunk ) = 0; };
Human knowledge belongs to the world.
-
Well - that tells you where the CollectionPtr comes from - it's a VB thing. OK, in that case you can explicitly define CollectionPtr yourself (look at how it's defined in the msvbvm60.tlh file) and remove the auto_search from the #import statement.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
please my friend , can you explain in more detail i am not c++ savvy be patient please with me i searched that file but i didn't find _CollectionPtr i found that struct __declspec(uuid("a4c46780-499f-101b-bb78-00aa00383cbb")) _Collection : IDispatch { // // Wrapper methods for error-handling // _variant_t Item ( VARIANT * Index ); HRESULT Add ( VARIANT * Item, VARIANT * Key = &vtMissing, VARIANT * Before = &vtMissing, VARIANT * After = &vtMissing ); long Count ( ); HRESULT Remove ( VARIANT * Index ); IUnknownPtr _NewEnum ( ); // // Raw methods provided by interface // virtual HRESULT __stdcall raw_Item ( /*[in]*/ VARIANT * Index, /*[out,retval]*/ VARIANT * pvarRet ) = 0; virtual HRESULT __stdcall raw_Add ( /*[in]*/ VARIANT * Item, /*[in]*/ VARIANT * Key = &vtMissing, /*[in]*/ VARIANT * Before = &vtMissing, /*[in]*/ VARIANT * After = &vtMissing ) = 0; virtual HRESULT __stdcall raw_Count ( /*[out,retval]*/ long * pi4 ) = 0; virtual HRESULT __stdcall raw_Remove ( /*[in]*/ VARIANT * Index ) = 0; virtual HRESULT __stdcall raw__NewEnum ( /*[out,retval]*/ IUnknown * * ppunk ) = 0; };
Human knowledge belongs to the world.
snouto wrote:
i searched that file but i didn't find _CollectionPtr
You won't find that explicitly. You'll find something like
COM_SMARTPTR_TYPEDEF(_Collection, __uuidof(_Collection));Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
how can i redefine explicitly that struct my friend , i don't get you well
Human knowledge belongs to the world.
Don't be so fscking impatient - you'll find it just irritates the people who are trying to help you.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Don't be so fscking impatient - you'll find it just irritates the people who are trying to help you.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Don't be so fscking impatient - you'll find it just irritates the people who are trying to help you.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Don't be so fscking impatient - you'll find it just irritates the people who are trying to help you.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
i am sorry my friend , i found that struct __declspec(uuid("a4c4671c-499f-101b-bb78-00aa00383cbb")) Collection; and that _COM_SMARTPTR_TYPEDEF(_Collection, __uuidof(_Collection)); so what can i do by this thing now
Human knowledge belongs to the world.
Put these two lines:
struct __declspec(uuid("a4c4671c-499f-101b-bb78-00aa00383cbb"))
Collection;_COM_SMARTPTR_TYPEDEF(_Collection, __uuidof(_Collection));
in your .cpp file before the
#importline. You probably need the definition (as opposed to declaration of _Collection as well - is there another definition of _Collection later in the tlh file, or in the tli file? If so - you need thatJava, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Sounds like it has dependencies on another COM object. Try adding 'auto_search' to your #import statement - that will attempt to resolve dependencies such as this without you having to alter your code by implicitly importing the other libraries that are required:
#import "some-comm-item" auto_search
HTH!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
I had the same problem importing msado15.dll, a solution was found on some Chinese forum[^], adding rename("EOF", "adoEOF") on the end of the import statement line for example,
#import "c:\program files\common files\system\ado\msado15.dll" no_namespace rename("EOF", "adoEOF")
In my case the error was raised on a line inside msado15.tlh with folowing code
__declspec(property(get=GetEOF))
VARIANT_BOOL EOF;So i suppose the conflict was on EOF being defined multiple times, and the rename solves this. HTH,... ;)
-
I had the same problem importing msado15.dll, a solution was found on some Chinese forum[^], adding rename("EOF", "adoEOF") on the end of the import statement line for example,
#import "c:\program files\common files\system\ado\msado15.dll" no_namespace rename("EOF", "adoEOF")
In my case the error was raised on a line inside msado15.tlh with folowing code
__declspec(property(get=GetEOF))
VARIANT_BOOL EOF;So i suppose the conflict was on EOF being defined multiple times, and the rename solves this. HTH,... ;)
Yes, I discovered that was the root cause as well - it was the same issue with the VB run-time - it defines EOF as well. I'd have found that out if I'd made a little sample app (as I often do), but as I do not have (and, given the opportunity, will never have) VB6 on my machine, I thought I wouldn't be able to import the VB6 run-time. I must confess that I decided not to post this alternate solution, as the OP seemed...satisfied, and I don't like adding confusion :-) Thanks for your post, anyway!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Yes, I discovered that was the root cause as well - it was the same issue with the VB run-time - it defines EOF as well. I'd have found that out if I'd made a little sample app (as I often do), but as I do not have (and, given the opportunity, will never have) VB6 on my machine, I thought I wouldn't be able to import the VB6 run-time. I must confess that I decided not to post this alternate solution, as the OP seemed...satisfied, and I don't like adding confusion :-) Thanks for your post, anyway!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I worked out that renaming things in the #import was the right solution (rather than the hack I suggested) well after my previous posts in this thread - that's why I didn't re-post and suggest it.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p