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

[Michael C. <mic...@gm...>]

Hi Thomas,

I really appreciate you taking the time to look at my patch, many thanks.

The idea about adding a dynamic keyword arg to createObject etc sounds 
fine to me. I had talked about this idea with another developer on my 
project, but we couldn't work out the best way to have invoke not 
generate code. Your idea about having a dyn_value on a variant sounds good.

I'm sure this will all work with the way you have proposed, but I would 
like to note, just so it is taken in to consideration, that when we use 
comtypes in NVDA, we generally don't make use of CreateObject etc, but 
rather we create a NULL interface pointer for the interface we are 
interested in, and then using byref, we use particular win32 api 
functions such as AccessibleObjectFromEvent in oleacc.dll to place the 
real pointer value in our pointer. This is because much of the time we 
retreave COM pointers from particular Windows etc.

So all I guess I'm saying here is that one of our use patterns with 
comtypes would be starting straight from an IDispatch which was 
arbitrarily retreaved, not necessarily through createObject etc. So as 
long as we can create a dynamic dispatch object with what ever means we 
see fit, and what ever attributes we ask for no code is generated, than 
this is fine.



However, your solution fits this model ok, I just wanted to point that 
out for future reference that is all.

Thanks again
Mick




Thomas Heller wrote:
> Michael Curran schrieb:
>> In regards to use cases, I guess the reason why I want this
>> functionality is for the main project I am working on, which is the NVDA
>> screen reader, at
>> http://www.nvda-project.org/
>>
>> In that project we use comtypes very heavily, for MSAA, SAPI, RichEdit
>> controls, etc. But for our support for MS Word and Excel etc, we
>> currently use pywin32. Reason being that with comtypes the COM
>> interfaces are just way too large and take way too long to generate.
>>
>> Pywin32 does a great job with dynamic dispatch, though its just annoying
>> having to use two Python COM implementations in the same project.
>>
>> So this is why I would like to improve comtypes dynamic dispatch support.
>>
>> I have also updated the patch, again, now fixing a few little issues
>> with the non-typeinfo dynamic dispatch support, and more importantly, I
>> have added some more tests to test_dyndispatch.py which tests many of my
>> code changes using MSAA objects.
>
> Michael,
>
> thanks for the patch and sorry for the late reply.  I have now made up my mind
> and have a plan how I want to integrate this into comtypes.
>
> 1. I will add new named parameter to the object creation functions in comtypes.client,
> CreateObject, GetActiveObject, and CoGetObject.  This parameter will be named
> 'dynamic' and will default to False.  If one of these functions is called with
> 'dynamic = True', then a dynamic dispatch object will be returned (an instance
> of comtypes.client.dynamic._Dispatch).  No wrapper code will be generated, and
> even if wrapper code is already there it will not be used.
>
> 2. It must be made sure that such an object will not trigger the code generation
> when an attribute is accessed or a method is called.  Since all attribute and
> method access goes through the 'IDispatch.Invoke' implementation in comtypes.automation,
> the last line in this method (which now is '   return result.value') this is the place
> where it can be implemented.  'result' is a VARIANT instance, and I will add a new
> property - maybe result.dyn_value - that will return a dynamic dispatch object.
>
> 3. There are some good ideas in your patch for comtypes.client.dynamic - thanks for that.
> But it seems there are still also a few problems with it which need to be fixed.
>
> I will release the current code ASAP as comtypes-0.5.1 before starting with these changes,
> hopefully it is not too late for you.
>