Thomas Heller schrieb: > Michael Curran schrieb: >> Hi, >> >> After testing with the dyndispatch svn branch of comtypes, I relised >> that there is a problem with dynamic Dispatch and IEnumVARIANT being >> used together. >> >> The problem is that If you enumerate a dynamic dispatch object (you get >> an IEnumVARIANT object some how from it), that IEnumVARIANT object >> doesn't know it has to provide dynamic=True to variant._get_value. So, >> the IEnumVARIANT's next method returns objects with fully generated >> interfaces, rather than just dynamic dispatch support. >> >> I would suggest that comtypes.automation.IEnumVARIANT have an instance >> variable called dynamic, which can be set to False by default. But if >> true, then the Next method should provide dynamic=True when getting >> variants.
This suggestion is now implemented. Here is the current state of the dyndispatch branch (in case Michael or someone else still cares about this stuff, which I hope!): The comtypes.client.CreateObject() function accepts an optional keyword argument 'dynamic' that defaults to False. The behaviour of the function is unchanged if 'dynamic=False', comtypes tries to generate and then imports the wrapper code for the object it creates. When CreateObject(..., dynamic=True) is called then no wrapper code is generated (well, if the object supports the IDispatch interface). If the com object exposes NO type information, then, as before, an instance of comtypes.client.dynamic._Dispatch is returned supporting method calls and property access by pure dynamic dispatch calls (GetIDsOfNames, and Invoke calls). If the com object exposes type information (and supports the ITypeComp interface), then an instance of the new module comtypes.client.lazybind.Dispatch is returned. Methods and properties are then bound by name, using ITypeComp.Bind() calls. Distributing the code for dynamic dispatch with or without type info over two different modules make the code a lot cleaner. > 3. Calling IDispatch.Invoke(...) is currently fairly slow. This is > because packing the arguments into the DISPPARAMS instance with ctypes > is very slow. This can probably be made a lot faster with a compiled > comtypes extension module. Also, the signature of IDispatch.Invoke() > in comtypes is wrong, it was a mistake to pass the invkind flags only > as keyword dictionary (and I thought it was clever!). This remains, but can be solved later if it turns out that it is really a problem. I would very much like to keep comtypes without any extension module, pure python. > 4. After playing around a little, I have the impression that it may be > better to create a separate subclass of a _Dispatch base class for > each COM object, and to generate the methods and properties in the > __init__ method from typeinfo. The big advantage is that the > resulting class has all methods (with parameter names!) and > properties that are available in the COM object, so code completion, > inspection, and so on will work. This I did not implement, it sounds much like early binding with all its problems that we want to get rid of. The dynamic dispatch code does everything on demand only (although I tried to cache the results of expensive calls to ITypeComp). -- Thanks, 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
