Type Library import in VC++
den...@gmail.com
application. I am using Visual Studio 2005. I tried it with both
#import directive and wizard->AddClass->FromTypeLib. Nothing seems to
work. Lately I found this article: http://support.microsoft.com/kb/307473.
I'm doing exactly as they say, however I'm not able even to compile
the project. Because of a huge amount of errors I receive during
compilation, I think that there some kind of basic problem I can't
find.
Here are some of compilation errors I receive when I try to build
project from http://support.microsoft.com/kb/307473:
--------------------------------------------------------------------------------------------------------------------------
...\debug\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition;
different basic types
c:\program files\microsoft visual studio 8\vc\include\comdef.h(312) :
see declaration of 'FontPtr'
...\debug\excel.tlh(1297) : error C2786: 'BOOL (__stdcall *)
(HDC,int,int,int,int)' : invalid operand for __uuidof
...\debug\excel.tlh(1297) : error C2923: '_com_IIID' : 'Rectangle' is
not a valid template type argument for parameter '_Interface'
c:\program files\microsoft visual studio 8\vc\platformsdk\include
\wingdi.h(3514) : see declaration of 'Rectangle'
...\debug\excel.tlh(1297) : error C3203: '_com_IIID' : unspecialized
class template can't be used as a template argument for template
parameter '_IIID', expected a real type
...\debug\excel.tlh(1301) : error C2786: 'BOOL (__stdcall *)
(HDC,int,int,int,int,int,int,int,int)' : invalid operand for __uuidof
...\debug\excel.tlh(1301) : error C2923: '_com_IIID' : 'Arc' is not a
valid template type argument for parameter '_Interface'
c:\program files\microsoft visual studio 8\vc\platformsdk\include
\wingdi.h(2765) : see declaration of 'Arc'
...\debug\excel.tlh(1301) : error C3203: '_com_IIID' : unspecialized
class template can't be used as a template argument for template
parameter '_IIID', expected a real type
...\debug\excel.tlh(1308) : error C2371: 'PicturePtr' : redefinition;
different basic types
c:\program files\microsoft visual studio 8\vc\include\comdef.h(326) :
see declaration of 'PicturePtr'
...\debug\excel.tlh(1689) : error C2504: '_IMsoDispObj' : base class
undefined
...\debug\excel.tlh(1731) : error C2504: '_IMsoDispObj' : base class
undefined
...\debug\excel.tlh(1852) : error C4430: missing type specifier - int
assumed. Note: C++ does not support default-int
...\debug\excel.tlh(1852) : error C4430: missing type specifier - int
assumed. Note: C++ does not support default-int
--------------------------------------------------------------------------------------------------------------------------
Please advice!
Thanks in advance,
Denis.
MrAsm
>I have a problem importing a Microsoft Office type libraries into my
>application. I am using Visual Studio 2005. I tried it with both
>#import directive and wizard->AddClass->FromTypeLib. Nothing seems to
>work. Lately I found this article: http://support.microsoft.com/kb/307473.
>...\debug\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition;
>different basic types
<cut>
I've tried the KB article step-by-step, and it works fine in VS2003.
(I don't have VS2005 and can't try with it.)
Moreover, I don't have this "excel.tlh" file... what is this file?
MrAsm
Scott McPhillips [MVP]
> I have a problem importing a Microsoft Office type libraries into my
> application. I am using Visual Studio 2005. I tried it with both
> #import directive and wizard->AddClass->FromTypeLib. Nothing seems to
> work. Lately I found this article: http://support.microsoft.com/kb/307473.
> I'm doing exactly as they say, however I'm not able even to compile
> the project. Because of a huge amount of errors I receive during
> compilation, I think that there some kind of basic problem I can't
> find.
I don't know if this will help you much, but I have encountered the same
problem and do not know the cause. I did find that the example works if
built in VC++ version 6, and then the project can be moved to VC++ 2005
without the #import directive.
I have found that the ATL approach works much better than the MFC
approach for Office COM interfaces. Here's a sample:
http://msdn2.microsoft.com/en-us/library/e85w507k(VS.80).aspx
--
Scott McPhillips [MVP VC++]
den...@gmail.com
works fine. However, I would like to know what do I have to do to
make it work in VS2005. It is hardly a bug, most likely there is
something in Project settings. Any help will be apreciated.
MrAsm
<org-dot-mvps-at-scottmcp> wrote:
>I have found that the ATL approach works much better than the MFC
>approach for Office COM interfaces. Here's a sample:
>http://msdn2.microsoft.com/en-us/library/e85w507k(VS.80).aspx
Yes, ATL is more COM-oriented than MFC.
Maybe, would it be easier for the OP to use VS2005 C++/CLI extensions
and COM Interop to automate Excel?
i.e. create the interop DLL from Excel typelib, and then use the
interop DLL using C++/CLI.
Maybe the COM Interop with C++/CLI extensions is easier than pure C++
and ATL?
MrAsm
Scott McPhillips [MVP]
> Yes, ATL is more COM-oriented than MFC.
>
> Maybe, would it be easier for the OP to use VS2005 C++/CLI extensions
> and COM Interop to automate Excel?
>
> i.e. create the interop DLL from Excel typelib, and then use the
> interop DLL using C++/CLI.
>
> Maybe the COM Interop with C++/CLI extensions is easier than pure C++
> and ATL?
>
> MrAsm
Well, let's be real clear: What would really be easier in this case
would be if Microsoft samples would compile with VC++ 2005. I've been
climbing the same learning curve as the OP and it has been very
depressing due to cruddy samples, cruddy documentation and
incompatibilities with older sample programs (from codeguru, codeproject
and two books I bought). It's a bloody minefield.
As for adding interop plus CLI extensions on top of Office on top of
COM, ... Sheesh! Way too much bloat for me.
MrAsm
<org-dot-mvps-at-scottmcp> wrote:
>Well, let's be real clear: What would really be easier in this case
>would be if Microsoft samples would compile with VC++ 2005.
I do agree.
>As for adding interop plus CLI extensions on top of Office on top of
>COM, ... Sheesh! Way too much bloat for me.
This is because you can manage ATL, so you can do direct Office COM
automation programming using ATL. But ATL is not trivial, and maybe
the OP could find easier to add some layers of architecture (even if
this is of course less efficient and more "bloat"), and manage Office
using the C++/CLI.
MrAsm
den...@gmail.com
Thanks for all your comments.
I did manage to compile the project.
Now I try to run the following code:
_ApplicationPtr spApp("Outlook.Application");
// Prepare a new mail message
_MailItemPtr olMail(spApp->CreateItem(olMailItem));
BSTR to = reinterpret_cast<BSTR>("t...@gmail.com");
olMail->put_To(to);
BSTR sbj = reinterpret_cast<BSTR>("Subject");
olMail->put_Subject(sbj);
BSTR bdy = reinterpret_cast<BSTR>("Hi James,\n\n"
"\tI'll see you in two minutes for our meeting!\n\n"
"Btw: I've added you to my contact list!");
olMail->put_Body(bdy);
// Send the message!
olMail->Send();
I get error in Send() : Unhandled exception at 0x7c57e592 in Auto.exe:
Microsoft C++ exception: _com_error at memory location 0x0012f3c0..
When I press BREAK it leads me to msoutl.tli file, Send() method.
Can someone please help me out here.
Thanks in advance.
SvenC
> Hi, guys!
> Thanks for all your comments.
> I did manage to compile the project.
> Now I try to run the following code:
> _ApplicationPtr spApp("Outlook.Application");
>
> // Prepare a new mail message
> _MailItemPtr olMail(spApp->CreateItem(olMailItem));
> BSTR to = reinterpret_cast<BSTR>("t...@gmail.com");
> olMail->put_To(to);
> BSTR sbj = reinterpret_cast<BSTR>("Subject");
> olMail->put_Subject(sbj);
> BSTR bdy = reinterpret_cast<BSTR>("Hi James,\n\n"
> "\tI'll see you in two minutes for our meeting!\n\n"
> "Btw: I've added you to my contact list!");
> olMail->put_Body(bdy);
>
> // Send the message!
> olMail->Send();
>
> I get error in Send() : Unhandled exception at 0x7c57e592 in Auto.exe:
When you use the #import wrappers created by default you will need to catch
_com_exception& as this is the way the wrappers signals HRESULTs with the
failure bit set. Debug into any method like put_To or Send and see that it
checks for FAILED(hr) and does a _com_issue_error if FAILED(hr) is true.
Second, try to avoid casting as much as you can, try to avoid
reinterpret_cast even harder.
You cannot create valid BSTRs the way you do. A C style string is layed out
differently in memory as a BSTR. BSTRs are created with SysAlloc-functions
and must be freed with SysFreeString. Use CComBSTR or _bstr_t to manage raw
BSTRs like so:
_bstr_t to(L"t...@gmail.com");
olMail->put_To(to);
--
SvenC
Scott McPhillips [MVP]
Please tell us how you got it to compile.
Have you used the debugger to look at the BSTR's? The
reinterpret_cast's you are using look like a bad way to try and set a
BSTR. Try BSTR to = _T("t...@gmail.com");
SvenC
>> // Prepare a new mail message
>> _MailItemPtr olMail(spApp->CreateItem(olMailItem));
>> BSTR to = reinterpret_cast<BSTR>("t...@gmail.com");
>
>
> Have you used the debugger to look at the BSTR's? The
> reinterpret_cast's you are using look like a bad way to try and set a
> BSTR. Try BSTR to = _T("t...@gmail.com");
Please not!
This is broken in the same way as the OPs code: the char array part looks
okay but a BSTR has its length prepended, so that null termination is not
mandatory. So when you do BSTR b = _T("hello world") and someone calls
SysStringLen(b) you are in undefined behaviour land. The same goes for
SysAllocFree. You must use a helper class like CComBSTR or _bstr_t if you
want automatic conversion with C strings.
--
SvenC
Mathews George
To solve this error try commenting statements like
#import "C:\\Program Files\\Microsoft Office\\Office12\\EXCEL.EXE" in class generated from type lib
> On Sunday, May 27, 2007 8:09 AM denis. wrote:
> I have a problem importing a Microsoft Office type libraries into my
> application. I am using Visual Studio 2005. I tried it with both
> I'm doing exactly as they say, however I'm not able even to compile
> the project. Because of a huge amount of errors I receive during
> compilation, I think that there some kind of basic problem I can't
> find.
> Here are some of compilation errors I receive when I try to build
> project from http://support.microsoft.com/kb/307473:
> =AD-----------------------------------------------
> .=2E.\debug\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition;
> c:\program files\microsoft visual studio 8\vc\include\comdef.h(312) :
> see declaration of 'FontPtr'
> c:\program files\microsoft visual studio 8\vc\platformsdk\include
> \wingdi.h(3514) : see declaration of 'Rectangle'
> parameter '_IIID', expected a real type
> c:\program files\microsoft visual studio 8\vc\platformsdk\include
> \wingdi.h(2765) : see declaration of 'Arc'
> parameter '_IIID', expected a real type
> c:\program files\microsoft visual studio 8\vc\include\comdef.h(326) :
> see declaration of 'PicturePtr'
> undefined
> .=2E.\debug\excel.tlh(1731) : error C2504: '_IMsoDispObj' : base class
> undefined
> .=2E.\debug\excel.tlh(1852) : error C4430: missing type specifier - int
> =AD-----------------------------------------------
> Thanks in advance,
> Denis.
>> <cut>
>>
>> I have tried the KB article step-by-step, and it works fine in VS2003.
>> (I do not have VS2005 and cannot try with it.)
>> Moreover, I do not have this "excel.tlh" file... what is this file?
>>
>> MrAsm
>>> On Sunday, May 27, 2007 10:48 AM Scott McPhillips [MVP] wrote:
>>> den...@gmail.com wrote:
>>>
>>> I don't know if this will help you much, but I have encountered the same
>>> problem and do not know the cause. I did find that the example works if
>>> built in VC++ version 6, and then the project can be moved to VC++ 2005
>>> without the #import directive.
>>>
>>> approach for Office COM interfaces. Here's a sample:
>>> http://msdn2.microsoft.com/en-us/library/e85w507k(VS.80).aspx
>>>
>>> Scott McPhillips [MVP VC++]
>>>>> On Sun, 27 May 2007 10:48:24 -0400, "Scott McPhillips [MVP]"
>>>>> <org-dot-mvps-at-scottmcp> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Yes, ATL is more COM-oriented than MFC.
>>>>>
>>>>> Maybe, would it be easier for the OP to use VS2005 C++/CLI extensions
>>>>> and COM Interop to automate Excel?
>>>>>
>>>>> i.e. create the interop DLL from Excel typelib, and then use the
>>>>> interop DLL using C++/CLI.
>>>>>
>>>>> Maybe the COM Interop with C++/CLI extensions is easier than pure C++
>>>>> and ATL?
>>>>>
>>>>> MrAsm
>>>>>> MrAsm wrote:
>>>>>>
>>>>>> Well, let's be real clear: What would really be easier in this case
>>>>>> climbing the same learning curve as the OP and it has been very
>>>>>> depressing due to cruddy samples, cruddy documentation and
>>>>>> incompatibilities with older sample programs (from codeguru, codeproject
>>>>>> and two books I bought). It's a bloody minefield.
>>>>>>
>>>>>> COM, ... Sheesh! Way too much bloat for me.
>>>>>>
>>>>>> Scott McPhillips [MVP VC++]
>>>>>>> On Sun, 27 May 2007 22:29:50 -0400, "Scott McPhillips [MVP]"
>>>>>>> <org-dot-mvps-at-scottmcp> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is because you can manage ATL, so you can do direct Office COM
>>>>>>> automation programming using ATL. But ATL is not trivial, and maybe
>>>>>>> the OP could find easier to add some layers of architecture (even if
>>>>>>> this is of course less efficient and more "bloat"), and manage Office
>>>>>>> using the C++/CLI.
>>>>>>>
>>>>>>> MrAsm
>>>>>>>> Hi, guys!
>>>>>>>> Thanks for all your comments.
>>>>>>>> I did manage to compile the project.
>>>>>>>> Now I try to run the following code:
>>>>>>>> _ApplicationPtr spApp("Outlook.Application");
>>>>>>>>
>>>>>>>> _MailItemPtr olMail(spApp->CreateItem(olMailItem));
>>>>>>>> BSTR to = reinterpret_cast<BSTR>("t...@gmail.com");
>>>>>>>> BSTR sbj = reinterpret_cast<BSTR>("Subject");
>>>>>>>> olMail->put_Subject(sbj);
>>>>>>>> BSTR bdy = reinterpret_cast<BSTR>("Hi James,\n\n"
>>>>>>>> "\tI'll see you in two minutes for our meeting!\n\n"
>>>>>>>> "Btw: I've added you to my contact list!");
>>>>>>>> olMail->put_Body(bdy);
>>>>>>>>
>>>>>>>> // Send the message!
>>>>>>>> olMail->Send();
>>>>>>>>
>>>>>>>> I get error in Send() : Unhandled exception at 0x7c57e592 in Auto.exe:
>>>>>>>> Microsoft C++ exception: _com_error at memory location 0x0012f3c0..
>>>>>>>> When I press BREAK it leads me to msoutl.tli file, Send() method.
>>>>>>>> Can someone please help me out here.
>>>>>>>> Thanks in advance.
>>>>>>>>> Hi Denis,
>>>>>>>>>
>>>>>>>>> When you use the #import wrappers created by default you will need to catch
>>>>>>>>> _com_exception& as this is the way the wrappers signals HRESULTs with the
>>>>>>>>> failure bit set. Debug into any method like put_To or Send and see that it
>>>>>>>>> checks for FAILED(hr) and does a _com_issue_error if FAILED(hr) is true.
>>>>>>>>>
>>>>>>>>> Second, try to avoid casting as much as you can, try to avoid
>>>>>>>>> reinterpret_cast even harder.
>>>>>>>>> You cannot create valid BSTRs the way you do. A C style string is layed out
>>>>>>>>> differently in memory as a BSTR. BSTRs are created with SysAlloc-functions
>>>>>>>>> and must be freed with SysFreeString. Use CComBSTR or _bstr_t to manage raw
>>>>>>>>> BSTRs like so:
>>>>>>>>>
>>>>>>>>> _bstr_t to(L"t...@gmail.com");
>>>>>>>>> olMail->put_To(to);
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> SvenC
>>>>>>>>>> den...@gmail.com wrote:
>>>>>>>>>>
>>>>>>>>>> Please tell us how you got it to compile.
>>>>>>>>>>
>>>>>>>>>> Have you used the debugger to look at the BSTR's? The
>>>>>>>>>> reinterpret_cast's you are using look like a bad way to try and set a
>>>>>>>>>> BSTR. Try BSTR to = _T("t...@gmail.com");
>>>>>>>>>>
>>>>>>>>>> Scott McPhillips [MVP VC++]