🚀 go-pugleaf

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

> No, it does not.  That is not how you are supposed to be handling COM
errors
> in the first place.  You need to check the HRESULT that the method
actually
> returns.  When everything is ok, the HRESULT is set to either S_OK or some
> other positive number.  A negative number indicates an error.  That is how
> COM determines whether an error actually occured or not.  For example:
>

This is my first COM base and Multi-thread Application please bear with me.

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

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

My assumation was that the overload functions was for convicence, since by
standard, a COM Method can only return HRESULT, 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

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

which is more clean and readable than

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

Also in VB the Method

 HRESULT         __fastcall sendSMS(BSTR SMSText/*[in]*/, BSTR
ToNumber/*[in]*/,
                                     BSTR* pVal/*[out,retval]*/);
was not expose rather

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

was expose using the same COM dll and on the same machine