>  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
Python-win32@[...].org
http://mail.python.org/mailman/listinfo/python-win32