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