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. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
