> 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). 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. > 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. > 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. Mark _______________________________________________ Python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
