Thanks for the clarification Tim.
My root problem is still the "Library not registered" issue. As far as
how it was registered:
* I maintain a dll that defines a class that implements I1 and I2. I
use regsvr to register this dll.
* I1 and I2 come from a third party, and in order for my dll to work
properly, it has to implement them (actually I2 is optional).
* I don't know how I1 and I2 are registered. I do know that if I use
the COM browser, I can go to Registered Type Libraries, find one with
the typelibname that is associated with my CastTo created objects,
which has "Type Library" underneath it, and underneath that are
entries for I1, I2, several related interfaces, and a variety of
coclasses. Like this:
- TypeLibName 1.0 TypeLibrary
-- IID: {00..00}
-- Type Library
--- I1 - Dispatch
--- I2 - Dispatch
--- IX - Dispatch
--- CX - CoClass
I've just spent some time hunting through the registry to determine
the differences between I1 and I2.
Looking the gen_py files, they have the same package CLSID, and the
same class coclass_clsid. But their class CLSIDs differ.
So I searched through the registry for those CLSIDs. They show up in
the same places, once each under HKEY_CLASSES_ROOT and
HKEY_LOCAL_MACHINE. Under each of them there is a "TypeLib" folder,
and within that, a "default" entry. The data associated with this
entry differs. In the case of I2, it's the same as the IID of the Type
Library I found in the COM browser. In the case of I1, it's another
GUID, but I don't know what it corresponds to.
Hopefully that sheds some light on the situation (or at worst, doesn't
confuse things further).
Thanks again,
Alec
On Wed, Sep 10, 2008 at 4:59 PM, Tim Roberts <[EMAIL PROTECTED]> wrote:
> 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, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
>
> _______________________________________________
> python-win32 mailing list
> python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
