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 > win32com.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 win32com.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 win32com 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. :-) > > 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 win32com\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 win32com? Thanks for your prompt reply to my somewhat vague questions :-) dave -- David W. Harks <[EMAIL PROTECTED]> _______________________________________________ Python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
