🚀 go-pugleaf

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:438b859f$1@newsgroups.borland.com...

> The first is the actual COM declaration.  The second is a Borland wrapper
> that calls the first one, as well as performs basic error handling to
throw
> an exception when a COM error is reported.

Then it will been more correct to alway call the second method and allow the
wrapper to do it basic function rather than bypass it by calling the first
(actual) declaration ie:

this

WideString result;
result = COMObj->sendSMS(WideString("test"),WideString("number"));

instand of this

WideString result;
if( COMObj->sendSMS(WideString("some text here"), WideString("some number
here"),  &result) >= 0 )


but off cousre within a try... catch().


> Yes.  However, you have to be careful with such code.  WideString has some
> quirky behavior that can cause memory leaks if you are not aware of how
you
> are using it.  In particular, WideString's BSTR constructor makes a copy
of
> the BSTR data but does not take ownership of the original BSTR, whereas
> WideString's BSTR '=' operator does take ownership of the original BSTR.
To
> ensure that the compiler does not accidently cause leaks to occur to your
> code, you should explicitally separate the construction of a WideString
from
> its assignment when passing COM strings to the WideString, ie:

What you are saying is that there is a difference between this

 WideString result;
 result = COMObj->sendSMS(WideString("test"), WideString("number"));

and this

 WideString result  = COMObj->sendSMS(WideString("test"),
WideString("number"));

and that the first is safer for  COM (thats a new one for me)

So far so good, all the above in from the COM user point of view, how about
from the COM developer point of view, which in this case is where i fall
within (Developer).

it more easier if am developing the COM to be used just within my own App.
but in this case my COM is targetted to third party developers.

is including the
public ISupportErrorInfoImpl<&IID_IesemesAPI>

and using
return Error(e.Message.c_str(), IID_IesemesAPI, E_UNEXPECTED);

to return Error good enough for my COM such that the third party developer
can use all the standard error handling routin you have mentioned so far
(for VB & C++).

Which of this method do i document for the COM user

this
 HRESULT         __fastcall sendSMS(BSTR SMSText/*[in]*/, BSTR
ToNumber/*[in]*/,  BSTR* pVal/*[out,retval]*/);

or this
 BSTR            __fastcall sendSMS(BSTR SMSText/*[in]*/, BSTR
ToNumber/*[in]*/);

other commerical COM API alway document the second.

Thanx
Darl