Fundamental COM incompatibility or newbie head-scratcher?

  • Thread starter Thread starter carl.clawson
  • Start date Start date
C

carl.clawson

Take a COM interface with a property declared like this:

[propget, id(1)] HRESULT SomeProperty([out] int *sideProperty, [out,
retval] int *mainProperty);

This is weird but in COM it returns sideProperty when you call it. It
even marshals correctly if you remote it.

..NET appears unable to read sideProperty out of the object, even
though the typelib-generated RCW shows it as a ByRef argument.

I've been having fun with this, but no luck yet.

Is there a better solution than writing a wrapper COM object to
present the other value as another property?
 
IJW ... It Just Works
Click to expand...

Unfortunately, "NID" ... No It Doesn't.

Up to now, interop has always "just worked" for me. I've used it
extensively for the last four or five years as I have lots of
libraries of COM objects that I use. Either I'm having a real stupid
day, or something's wrong here.

Here's my COM code, in C++:

STDMETHOD(get_IntSideEffect)(/*[out]*/ int *sideEffect, /*[out,
retval]*/ int *pVal)
{
*pVal = 22;
ATLTRACE("Copying int, incoming = %d\n", *sideEffect);
*sideEffect = 42;
ATLTRACE("Copied int, outgoing = %d\n", *sideEffect);
return S_OK;
}

And in VB.Net 2005 I call it thus:

Dim sideEffect As Integer = 7
Dim out As Integer = obj.IntSideEffect(sideEffect)
' sideEffect is still = 7

The trace statements in the C++ code report 7 as the incoming value
and 42 as outgoing. But in VB, sideEffect is still 7 after the call.
It's like it never gets marshaled all the way out.
 
Back
Top