🚀 go-pugleaf

"Darlington ADIBE" <bcb@triative.com> wrote in message
news:438b5b9d@newsgroups.borland.com...

> When I used the Type Lib Editor to add the method
> sendSMS to the COM Interface, the editor added
> this two declearation to the file

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.

> My assumation was that the overload functions was for convicence

That is correct.

> the second overload method was add to call the origainal method
> and handle the return of the BSTR, thereby allowing a programmer
> to used code like

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:

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

> which is more clean and readable than

Yes, it is more clean.  But you are not taking into account that the wrapper
code has the potential of throwing an exception.  So you should always make
sure that your code is exception-safe when using the COM object.

> Also in VB the Method
>
>  HRESULT         __fastcall sendSMS(BSTR SMSText/*[in]*/,
> BSTR ToNumber/*[in]*/, BSTR* pVal/*[out,retval]*/);
> was not expose

Yes, it is.  Non-Borland environments can only see what is actually in the
Type Library.  They never see the wrapper code at all.  Do not get confused
by the fact that VB has a similar syntax to what Borland's wrapper code
allows.  VB has its own built-in wrappers for COM operations.  Like I said
earlier, VB is very closely integrated with COM.  A lot of COM's
complexities are hidden to VB users.

For example, this VB code, which does not use the 'On Error' mechanism:

    Dim result
    result = COMObj.sendSMS("test", "number")

Is equivilent to this C++ code:

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

However, this VB code, which does use the 'On Error' mechanism:

    Dim result
    On Error Resume Next
    result = COMObj.sendSMS("test", "number")
    If Err.Number <> 0 Then MsgBox Err.Description
    // do something else...

Is equivilent to this C++ code:

    WideString result;
    if( FAILED(COMObj->sendSMS(WideString("test"), WideString("number"),
&result)) )
    {
        TComInterface<IErrorInfo> Err;
        WideString Desc;
        if( GetErrorInfo(0, &Err) == S_OK )
            Err->GetDescription(&Desc);
        ShowMessage(Desc);
    }
    // do something else...

Or this C++ wrapper code:

    WideString result;
    try
    {
        result = COMObj->sendSMS(WideString("test"), WideString("number"));
    }
    catch(const Exception &)
    {
        ShowMessage(E.Message);
    }
    // do something else...

>   BSTR            __fastcall sendSMS(BSTR SMSText/*[in]*/, BSTR
> ToNumber/*[in]*/);
>
> was expose using the same COM dll and on the same machine

Wrong.  That method is not in the COM DLL at all.  It is only in Borland's
wrapper code that you end up including into your Application executable.


Gambit