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. 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. The second method takes
an integer, a VT_TYPE, and a variant. I don't know if the
representation here accurately represents that.
The first parameter seems to be the ID of the method within the
interface (or something similar), and given that I2 only has a single
method, "1" seems like it could be correct.
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?
Thanks, hopefully this helps someone.
Alec
On Tue, Sep 2, 2008 at 1:44 PM, Alec Munro <[EMAIL PROTECTED]> wrote:
> I'm guessing, based on the lack of responses, and the consistency of
> error messages, that my problem has more to do with getting the right
> library registered, which isn't a python-win job.
>
> So, can anyone recommend where I might go to try to solve this
> problem? Also, is there a way to determine which library it is that is
> not registered?
>
> Thanks again,
>
> Alec
>
> On Fri, Aug 29, 2008 at 2:47 PM, Alec Munro <[EMAIL PROTECTED]> wrote:
>> Thanks Mark.
>>
>> After a couple of misfires, I think I figured out how to get CastTo to
>> work (the docstring is practically non-existent in the version I have,
>> perhaps it's been updated?).
>>
>> However, that puts me back at the same place I was with some of the
>> other attempts:
>>
>>>>> obj_i2 = CastTo(obj, "Interface_2")
>>>>> obj_i2.secondaryMethod()
>> Traceback (most recent call last):
>> ...
>> File "C:\Python25\lib\site-packages\win32com\client\__init__.py",
>> line 449, in _ApplyTypes_
>> dispid, 0, wFlags, retType, argTypes, *args),
>> com_error: (-2147319779, 'Library not registered.', None, None)
>>
>> However, one interesting note is that the object generated by CastTo
>> is of a different version of the Type Library than the object
>> generated by Interface_2(obj). I don't know if that's useful
>> information, however. They have the same CLSID, but different
>> coclass_clsids.
>>
>> Thanks again,
>>
>> Alec
>>
>> On Fri, Aug 29, 2008 at 3:01 AM, Mark Hammond <[EMAIL PROTECTED]> wrote:
>>> Look at the docstring for win32com.client.CastTo (and googling for that will
>>> probably help too)
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>> I just discovered a third possibility, and subsequent failure:
>>>>
>>>> >>> obj_i2 = Dispatch(obj, None, Interface_2.CLSID)
>>>> >>> obj_i2.secondaryMethod()
>>>> Traceback (most recent call last):
>>>> ...
>>>> File "C:\Python25\lib\site-packages\win32com\client\__init__.py",
>>>> line 449, in _ApplyTypes_
>>>> dispid, 0, wFlags, retType, argTypes, *args),
>>>> com_error: (-2147352573, 'Member not found.', None, None)
>>>>
>>>> Alec
>>>>
>>>> On Thu, Aug 28, 2008 at 10:33 AM, Alec Munro <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > Oh, and on re-reading, I do realize that the DLL itself doesn't
>>>> > implement those interfaces. There's a class within the DLL that does
>>>> > that. :)
>>>> >
>>>> > On Thu, Aug 28, 2008 at 10:32 AM, Alec Munro <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >> Hi List,
>>>> >>
>>>> >> Hopefully I have my terminology right, I'm pretty new to COM and
>>>> C++.
>>>> >>
>>>> >> My problem is that I have a COM DLL written in C++, that I would
>>>> like
>>>> >> to call from Python. This DLL implements 3 important interfaces,
>>>> each
>>>> >> of which is also an IDispatch implementation, like the following:
>>>> >>
>>>> >> IDispatchImpl<Interface_1, &__uuidof(Interface_1),
>>>> &LIBID_Interface_1, 1, 0>
>>>> >> IDispatchImpl<Interface_2, &__uuidof(Interface_2),
>>>> &LIBID_Interface_2, 1, 0>
>>>> >> IDispatchImpl<Interface_3, &__uuidof(Interface_3),
>>>> &LIBID_Interface_3 1, 0>
>>>> >>
>>>> >> However, when I do:
>>>> >>>>> obj = win32com.client.Dispatch("a.b.c")
>>>> >>>>> obj
>>>> >> <COMObject a.b.c>
>>>> >>
>>>> >> The object I get only has methods available for the first of the
>>>> >> interfaces. From my reading, this is simply the functionality of
>>>> >> IDispatch, and if I wanted to get those additional methods through
>>>> >> IDispatch, I would have to update the DLL, and restructure my
>>>> >> interfaces. I'm not confident enough in my C++ to do this, or at
>>>> least
>>>> >> it's not my first choice.
>>>> >>
>>>> >> From what I've read, there are two ways that seem to be
>>>> possibilities
>>>> >> for being able to call the methods from the other interfaces.
>>>> >>
>>>> >> The simplest one I found was the suggestion to use MakePy on the
>>>> type
>>>> >> library containing Interface_2 and Interface_3. I did this, and
>>>> copied
>>>> >> the generated file to my working directory, then did:
>>>> >>
>>>> >>>>> from interfaces import Interface_2
>>>> >>>>> obj_i2 = Interface_2(obj)
>>>> >>>>> obj_i2
>>>> >> <win32com.gen_py.typelibname 1.0 Type Library.Interface_2 instance
>>>> at
>>>> >> 0x17459602>
>>>> >>
>>>> >> Unfortunately when I try:
>>>> >>
>>>> >>>>> obj_i2.secondaryMethod()
>>>> >> Traceback (most recent call last):
>>>> >> ...
>>>> >> File "C:\Python25\lib\site-packages\win32com\client\__init__.py",
>>>> >> line 449, in _ApplyTypes_
>>>> >> dispid, 0, wFlags, retType, argTypes, *args),
>>>> >> com_error: (-2147319779, 'Library not registered.', None, None)
>>>> >>
>>>> >> The other suggestion I came across was to use QueryInterface. I
>>>> wasn't
>>>> >> sure what argument to pass to QueryInterface, so I tried using the
>>>> >> CLSID of the interface I wanted.
>>>> >>
>>>> >>>>> obj._oleobj_.QueryInterface(Interface_2.CLSID)
>>>> >> Traceback (most recent call last):
>>>> >> File "<interactive input>", line 1, in <module>
>>>> >> TypeError: There is no interface object registered that supports
>>>> this IID
>>>> >>
>>>> >> From these error messages, it seems like perhaps there's a problem
>>>> >> with the registration of the type library that contains the
>>>> >> interfaces. I'm not really sure how to fix that, or if that is even
>>>> >> the problem.
>>>> >>
>>>> >> Any ideas?
>>>> >>
>>>> >> Thanks,
>>>> >> Alec Munro
>>>> >>
>>>> >
>>>> _______________________________________________
>>>> 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
