Hello everyone,
Just seeing if I can open up this issue with a bit more information. I am
trying to access the COM interface to Documentum as well. I ran into the
same problems that David did. Basically, that it appears makepy gets
utterly confused when generating the information for the DFC COM interface.
Makepy runs, without any errors, but the outputted library information is
incorrect. I did some inspection myself to see what's up. As an example,
I'll take the IDfClientX interface, and specifically, the getDFCVersion()
method that takes no parameters. After creating, Makepy, the definition is
as follows in the generated code.
def getDFCVersion(self):
# Result is a Unicode object - return as-is for this version of
Python
return self._oleobj_.InvokeTypes(23, LCID, 1, (8, 0), (),)
Now if I'm running things myself after Makepy, and I have an IDfClientX
object, if I call GetTypeInfo(23) on the _oleobj_ of the IDfClientX object,
I get the typeinfo for the method. If I call GetFuncDesc(23).memid I get
17. If I call
GetIDsOfNames(_oleobj_.GetTypeInfo(i).GetDocumentation(i)[0]), I get 40,
which is the correct value.
If I go back to the generated code from Makepy, and manually change all
references of 23 to 40 for getDFCVersion, the call to this method will work
correctly.
I attempted to inspect MakePy.py to see if I could simply add a call to
GetIDsOfNames to get the correct ID, but unfortunately this fails. I put in
some logging information for MakePy before the _AddFunc_ method of build.py,
just before an entry is added to the function map. When the entry is added,
a call to GetIDsofNames returns 23, and the funcdesc.memid variable is also
23. I can get no reference to the correct ID of 40. In short, it appears
that during generation, MakePy's calls to get ids only returns the index of
the method in the COM interface (i.e. the x you need to put in
GetTypeInfo(x) to get the TypeInfo.
Anyone have any ideas here, I'll be the first to admit, I only have limited
knowledge of Python and COM. It seems that there should be a way to coax
correct values out of this since Python is cabable of getting the correct
IDs.
Any help is appreciated.
Thanks,
--Tom
With carefully-arranged electrons, Mark Hammond wrote:
> Unfortunately, the dynamic dispatch and makepy utilities don't get the
> correct IDs for the various methods -- which are often object factories
> that lead to more dispatches.
I'm not sure what you mean by "dynamic dispatch", but if you explicitly use
win32*com*.client.dynamic.DumpDispatch(), you should find the object is only
calling GetIDsFromNames() on the object (which you later said does work).
By dynamic dispatch, I was referring to simply calling
win32*com*.client.dynamic.Dispatch(). What's really interesting is that I
get a third result from doing the DumbDispatch(); in that case the
methods on the object return a string with the *Java* object name. So the
*COM*-*Java* bridge (or something about the underlying *Java* implementation)
seems to be at work here. The type library has the right types, but the
wrong enumeration of dispid's.
However, makepy (and a normal Dispatch() in many cases) does things
differently - it asks the object for its "typeinfo", and builds up a map of
all the available methods and properties.
As the win32*com* dispid mapping works for the vast majority of objects, it
would appear possible that the typeinfo retrieved for the object is not
accurate.
Okay, that makes sense. At least that would let me go back to the vendor
and request that they update their typelib. [image: :-)]
> Obviously, manually going through the generated file and updating the
> IDs is not a great solution, so I'd like to patch build.py...
>
> But I really have no idea where to start. Any hints? Even an idea of
> what methods to look at would be much appreciated.
I've no idea where to start as I've no idea what kind of patch you are
after. Looking at the _Build_Interface() method in win32*com*\client\genpy.py
would be a reasonable start, and is probably the place where we iterate over
the typeinfo and get the (apparently wrong) dispid and param information.
I was hoping for something that would allow build.py to detect this case
and handle it; of course based on what we've found that might not be
possible.
> Oh, I should mention that Documentum's *COM* objects are implemented via
> the *COM*-*Java* bridge, which could be related, though I'm not sure.
That certainly sounds a likely candidate - OTOH, if the bridge itself is
incorrect I'd expect other languages that introspect the typeinfo to also
fail in similar ways. Sadly, VBScript is probably unable to use the
typeinfo in that way, and depending on how the interface is defined, VB
itself may just jump directly to the vtable interface and also avoid getting
IDispatch info from the typelib.
Is there any way to use the vtable interface through win32*com*?
Thanks for your prompt reply to my somewhat vague questions [image: :-)]
dave
--
David W. Harks <dave <at> psys.org>
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
