Re: Passing pointers using a VARIANT

<muybluie@xxxxxxxxxxx> wrote in message
news:fa73851c-f54b-40f9-aad4-7104def850d9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have an in-proc COM server (i.e. a COM DLL) that I need to use. I
want to pass a pointer to a class I defined to a method defined in one
of the DLL's interfaces.

You don't pass classes in COM - you pass interface pointers.

Did you implement this DLL? Why do you believe it needs to be a COM DLL?
Why not just make it a regular DLL exporting a set of functions and
perhaps classes? You are trying to do decidedly non-COM-friendly
things - I wonder what benefits of COM do you expect to gain.

So, my COM DLL has a method like Foo( [in] VARIANT ).

So far, the only way I can get that to work is if I cast the pointer
to a long and snaeak it in through the lVal member of the VARIANT. My
guess is that the minute I use something like VT_VOID | VT_BYREF, some
marshaling is attempted, and this fails.

What's the threading model of the component? What apartment does the
thread join that creates this component? Is the class whose pointer you
are trying to sneak through thread-safe?

1. Is my guess correct?

Possibly.

Why is an inproc call even
marshalled?

Because the caller and the callee have incompatible threading models.
For more details, see

http://support.microsoft.com/kb/150777

2. How can I use the VAIRIANT to pass the pointer correctly?

You define an interface, have your class implement this interface, and
pack the interface pointer into VARIANT of type VT_UNKNOWN or
VT_DISPATCH.

Should I
be using something else?

You should be using COM. You are not.

For those of you appalled that I would even try something like this:
this COM DLL is legacy code, soon to be replaced by a regular C++
DLL.

So you don't have control of the callee side's source code? Then you
have no choice - you have to set up the VARIANT exactly the way the
method expects it.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: hosting the runtime
    ... >> and you know the name of the DLL. ... >> usually created by class factory objects, ... >> class to this function and it will return the class factory interface of ... >> so all you get back is a pointer to a table of pointers). ...
    (microsoft.public.dotnet.framework)
  • Re: hosting the runtime
    ... its worth pointing out that a COM interface is very much like a ... class and you know the name of the DLL. ... objects are usually created by class factory objects, ... v-table pointer, so all you get back is a pointer to a table of ...
    (microsoft.public.dotnet.framework)
  • Re: hosting the runtime
    ... its worth pointing out that a COM interface is very much like a C++ ... > and you know the name of the DLL. ... > usually created by class factory objects, ... > so all you get back is a pointer to a table of pointers). ...
    (microsoft.public.dotnet.framework)
  • Re: Why we must use class factory to create some objects in COM?
    ... A dll can expose more than one component.Do u agree with this?If so, ... Instead of calling CoCreateInstancewhich just gives only one interface ... pointer of a component u can use ... You say it can create any number of components using class factory, ...
    (microsoft.public.vc.mfc)
  • Re: Properties Shared Amongst Objects
    ... The host can query my application for certain ... In that context one usually strives to provide a subsystem interface that reflects the invariants of the DLL subject matter. ... A some point the conversion may become so complex that one wants to deal with it explicitly within the DLL subject matter. ...
    (comp.object)
Loading