VB Forum / COM / February 2005

shekar,

Forgive me if your example was a typo or something, but first of all if you
use 'Call' the return value is swallowed up by VB. So in order to get a
return you have to provide one...
    Dim lRtn As Long
    lRtn = SomeFunction( str )

But don't get too excited yet! <g> This return will *NOT* be the HRESULT, it
will be whatever you defined in the IDL as [in, retval], should be the last
parameter in the argument list, and should be of type pointer-to the 'real'
value you want to return. eg, long*, BSTR*, &etc.

    HRESULT SomeFunction( [in, out] BSTR* str, [out, retval] long* lRtn );

According to the rules of COM, or Automation in this case (you did define
your interface in the IDL as 'automation' or 'dual', right?), the HRESULT is
always made available to the transport layer  (not the user) so that it can
play around with it (ignore, add its own, etc.). In the case of VB it ends
up the VB Runtime, and is often 'converted' to a VB Runtime error.

For example, an E_INVALIDARG ends up as a VB Runtime Error 5 "Invalid
procedure call or argument". I think a E_NOINTERFACE  would end up as a 425
or 426 "Method not supported by object" or something like that. (don't hold
me to this I am just winging it, with no reference material, and my memory
isn't that good. <g>).

So to catch the "HResult" (kind of) you can use VB built in structured error
hander. The ErrorObject in VB is essentially just a wrapper for the
EXCEPINFO struct implementing an interface to the members...

On Error Goto ErrorHandler
    Dim lRtn As Long
    lRtn = SomeFunction( str )
    Exit
ErrorHandler:
       ' right out of the struct...
   Debug.Print Err.Source   ' bstrSource
   Debug.Print Err.Description  ' bstrDescription
   Debug.Print Err.HelpFile       ' bstrHelpFile
   Debug.Print Err.HelpContext  ' bstrHelpContext

' ignore this... <g>
'Debug.Print Err.LastDLLError ' returned from Windows system API calls

   Debug.Print Err.Number       ' usually the runtime error
      ' you can catch the error from the OLE transport (usually the
HRESULT)
      ' like this...
   Dim lHR As Long
   If Err.Number And vbObjectError Then
        lHR = Err.Number XOr vbObjectError.
   End If

Note I said 'usually'! The HResult, according to the rules of com, might
actually get changed. (based on the wCode, or something else.)

I realize it looks a bit contrieved, but VB is actually only following the
rules. It is only because it is so easy to violate the rules in C/C++ that
makes makes VB's handling look so strange.

hth
-ralph