Thread: [comtypes-users] thoughts and a patch for dynamic IDispatch

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

I am one of the core developers for the NVDA screen reader at
http://www.nvda-project.org/

We use comtypes very heavily in our project, mostly for access to MSAA, 
RichEdit, MSHTML, and SAPI speech synthesizers.

However, for access to such apps as MS Word, MS Excel etc, we tend to 
use pywin32, for the single reason that comtypes interfaces for these 
apps can take so long to generate, plus pywin32 has very good dynamic 
IDispatch support.

Pywin32 is great, but it is annoying switching between python COM 
implementations, we would rather just use one or the other.

This is the reason why I have created a patch for latest comtypes trunk, 
which improves its support for dynamic IDispatch, making it now possible 
to fully depend only on dynamic IDispatch, with out having to generate 
any interfaces when going from one IDispatch object to another etc.

Firstly, a variable called 'disableCodeGeneration' has been added to the 
base comtypes package. If you do not wish for any COM interfaces to be 
generated by comtypes if it has to, set this to True. It is False by 
default.

comtypes.client._generate._createWrapper now throws an exception, if 
disableCodeGeneration is True and it finally gets to the point where it 
must generate some interfaces (they didn't exist already or they are out 
of date).

comtypes.client.GetBestInterface now tries returning a dynamic.Dispatch 
object if at any time there is an error. e.g. the interface couldn't be 
found or created etc.

So with just these changes, if you have no already generated interfaces, 
and you make a dynamic Dispatch object some how, now if any of its 
methods or properties return IDispatch objects, rather than them being 
smartly wrapped in real generated interfaces, dynamic Dispatch objects 
are just returned instead.

So the rule is: with disableCodeGeneration set to True, if the interface 
already exists it will use it, but if it doesn't and it supports 
IDispatch, it will use dynamic Dispatch, rather than trying to generate 
proper interfaces.

I also made some changes to comtypes.client.dynamic._Dispatch, so that 
it works nicer with properties and methods.

It now makes use of ITypeComp, using Bind to get IDs and invKind info 
from a name. It also caches as much information as it can to make sure 
its as fast as possible.

Note that information is cached by its guid and name, on the actual 
dynamic Dispatch class, so that multiple uses of the same IDispatch type 
stay just as fast.

So now, the only time an IDispatch property is treeted as a property 
(i.e. doesn't have to be called like a function) is if its invkind is 
propget and it has no params or optional params. Otherwise the method 
caller is used instead.

examples in MS Word are:
range.text is a property
range.collapse() is a method
examples in MSAA are:
pacc.accName() or pacc.accName(0)  The property has an optional argument 
so therefore it has to be treeted as a method.
pacc.accFocus is a property with no arguments at all, so it can be 
treeted as a property.

__call__ has also been added to _Dispatch, so that the IDispatch's 
default method can be called, by calling the dynamic Dispatch object 
like a function.
An example of this is an MS Word paragraphs object, calling 
paragraphs(1) will now work.

Also __enum now tries querying directly to IEnumVARIANT, if it fails to 
call _enum. This now means that MSAA objects that have an IEnumVARIANT 
as as one of their interfaces will now work pythonicly as a list/iterater.

This patch makes dynamic._Dispatch rely on the fact that the IDispatch 
object has ITypeInfo via GetTypeInfo(0). The question i have is is this 
true for all IDispatch objects? or should we still support the more 
basic GetIdsOfNames and then just treet all properties as methods, if 
ITypeComp can't be found?

A completely different approach to this could be where if a dynamic 
Dispatch object calls invoke, and invoke returns an IDispatch, then we 
should wrap it as a dynamic Dispatch object rather than getting its best 
interface. However, I am not sure if this could currently be at all 
possible in comtypes as we would need to be able to detect the fact that 
invoke was called from a dynamic Dispatch object, as its result gets 
wrapped... at a very low level. I think for now, allowing the user to 
refuse code generation better suits the pattern of use.

What are people's thoughts on this?

Mick