Michael Curran schrieb: > Hi Tim, > > I wasn't aware Thomas was away, thanks for letting me know. He just > suggested to me the other week that I should join and start a discussion > on here about the patch. > > 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.
Michael, I can understand that you feel like this, however let me play devils advocate. The code generation takes long, sure, but it is only done once. Also, you *could* generate when building the distribution and distribute them with your own code anyway. And what's the problem with the size? The NVDA zipfile is 11 MB, and the installer is 8.4 MB already, are a few MB more such a big deal? The problem with (parts of) your patch is that I fear there will be different behaviour in code using comtypes depending on what the 'disableCodeGeneration' current value is (and the *user* of our code is controlling the value of this variable), and additionally different behaviour depending on whether generated code is present or not even if the code generation is disabled. I can imagine several ways to fix that, possibly allowing the programmer to choose between dynamic dispatch and the custom part of dual interfaces: 1. It may be possible to explicitely specify that you want a dynamic object on COM object creation. Maybe introducing a comtypes.client.Dispatch() function in addition to comtypes.client.CreateObject(), similarly for the other creation function comtypes.client.GetActiveObject(). The returned *dynamic* dispatch objects/interfaces would probably have an attribute that prevented code generation for anything retrived from them. 2. Another approach would be to always use the automation interface if the object supports it. There may be other ways that escape me at the moment. > 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. > Thomas ------------------------------------------------------------------------- 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
