[python-win32] Accessing other interfaces of a Dispatch created COM object

[Tim Roberts]

Alec Munro wrote:
> Ok, perhaps this will be useful.
>
> (Neither of these examples include the core arguments of the methods,
> just the ones specific to InvokeTypes)
>
> What I call a method from I1, it calls _oleobj_.InvokeTypes with the
> following arguments:
>
> 18, 0x0, 1, (24, 0), ((8, 1),)
>
> When I use the method from I2, it calls _ApplyTypes_(), which calls
> _oleobj_.InvokeTypes with the following arguments:
>
> 1, 0x0, 1, (24, 0), ((3, 1), (12, 1), (16396, 2))
>
> Now, from my reading (of old messages by Mark :) ), the last two
> parameters specify method return type and argument type.

Well, it's the 4th argument that gives the return type.  24 is VT_VOID. 
That's unusual for a COM type.

> In this case,
> it seems like both methods return VOID, which seems fine. I'm a little
> more concerned about the argument type. The first method is supposed
> to take a single string, so that looks fine.

Right; 8 is VT_BSTR, which is the typical COM Unicope string type.

> The second method takes
> an integer, a VT_TYPE, and a variant. I don't know if the
> representation here accurately represents that.
>   

3 is VT_I4 (long), 12 is VT_VARIANT, and 16396 is a VT_VARIANT passed by
reference, meaning an output parameter.

> So, I'm fairly certain this puts that problem at something that
> happens in InvokeTypes, unrelated to the arguments I passed in. I get
> the impression that InvokeTypes is something of Microsofts, and
> there's isn't really any way to observe what it's doing?
>   

I've lost track.  What's the root problem?  Is it still  the "Library
not registered" issue when you call a method in Interface_2?  Was this
all registered through a type library, or through a regsvr32 call, or what?

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.