#import [out,retval] ?

Hello,
I wrote an ATL in-proc server for use with VBA and MFC. In the MFC code, I
am using #import on the server's type library. MFC complains about interface
methods with an [out,retval] parameter. I can add a second copy of the
method to the interface with a new name and the [out,retval] changed to just
[out]. This seems to work. Is there a way to get rid of the errors without
adding a bunch of (almost) redundant methods to the interface?

--
Bill Swartz, PhD
Voss Scientific

Kim
Sun Aug 17 14:51:35 CDT 2003

Bill,

Please post:
- IDL for the ATL server
- #import statement
- The exact error message you get

Best regards,
Kim

Bill Swartz wrote:
> Hello,
> I wrote an ATL in-proc server for use with VBA and MFC. In the MFC
> code, I am using #import on the server's type library. MFC complains
> about interface methods with an [out,retval] parameter. I can add a
> second copy of the method to the interface with a new name and the
> [out,retval] changed to just [out]. This seems to work. Is there a
> way to get rid of the errors without adding a bunch of (almost)
> redundant methods to the interface?

Kim
Mon Aug 18 10:35:35 CDT 2003

Hi Bill,

> #import "..\\officeHelp\\officeHelp.tlb"
>
> G:\PWG\pwgDll\paramsWorkBook.cpp(200) : error C2660: 'getRowFromSheet' :
> function does not take 3 parameters
>
> Since I posted the message, I have learned that the 'raw_' versions of the
> methods at least compile with no errors. I will test the executables.

Ah, that clears it up. #import generates wrapper classes for you (IxxxPtr),
which transform [out, retval] into actual C++ return values, and the HRESULT
is mapped to an exception. You can open up the generated .tlh and .tli files
to see how #import does its magic (or at least what the magic result it)

If you want to stay with raw types, you should decorate #import like so:

#import "..\\officeHelp\\officeHelp.tlb" raw_native_types
raw_interfaces_only

This should throw no exceptions, nor produce wrappers.

Alternatively, if you're comfortable with exception handling, use the
wrappers directly:

IOfficeHelperPtr pOH(__uuidof(OfficeHelper));
_variant_t pRange = pOH->getRowFromSheet(foo, bar);

Note that any failure in the call chain will throw a _com_error exception
that you need to handle accordingly.

--
Best regards,
Kim Gräsman

Bill
Mon Aug 18 13:24:02 CDT 2003

Thanks. I am now using raw interfaces. The non-raw versions were loosing
error info that my server creates with AtlReportError.
"Kim Gräsman" <kim@mvps.org> wrote in message
news:ujaIQ5ZZDHA.2308@TK2MSFTNGP12.phx.gbl...
> Hi Bill,
>
> > #import "..\\officeHelp\\officeHelp.tlb"
> >
> > G:\PWG\pwgDll\paramsWorkBook.cpp(200) : error C2660: 'getRowFromSheet' :
> > function does not take 3 parameters
> >
> > Since I posted the message, I have learned that the 'raw_' versions of
the
> > methods at least compile with no errors. I will test the executables.
>
> Ah, that clears it up. #import generates wrapper classes for you
(IxxxPtr),
> which transform [out, retval] into actual C++ return values, and the
HRESULT
> is mapped to an exception. You can open up the generated .tlh and .tli
files
> to see how #import does its magic (or at least what the magic result it)
>
> If you want to stay with raw types, you should decorate #import like so:
>
> #import "..\\officeHelp\\officeHelp.tlb" raw_native_types
> raw_interfaces_only
>
> This should throw no exceptions, nor produce wrappers.
>
> Alternatively, if you're comfortable with exception handling, use the
> wrappers directly:
>
> IOfficeHelperPtr pOH(__uuidof(OfficeHelper));
> _variant_t pRange = pOH->getRowFromSheet(foo, bar);
>
> Note that any failure in the call chain will throw a _com_error exception
> that you need to handle accordingly.
>
> --
> Best regards,
> Kim Gräsman
>
>

Igor
Mon Aug 18 14:49:12 CDT 2003

"Bill Swartz" <bills@vosssci.com> wrote in message
news:eZvIoXbZDHA.628@TK2MSFTNGP10.phx.gbl...
> Thanks. I am now using raw interfaces. The non-raw versions were
loosing
> error info that my server creates with AtlReportError.

They shouldn't. They throw an exception of type _com_error on COM error,
and _com_error has methods for retrieving all the rich error info. Does
your COM component implement ISupportErrorInfo?
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken