Hi Thomas, The new changes to the dyndispatch branch sound great.
I'm definitely still interested in the branch, and am hoping that once its stable enough that it can be merged in to trunk so I can start using it properly in the NVDA project. I havn't fully tested out all the changes you mentioned yet, but from what you have written, they all sound ok to me. I'm also glad you decided against any early binding, as they really would have limited performance, specially if the user was not going to use a lot of the methods on a particular interface. One thing: comtypes.client.lazybind.NamedProperty. You ask in the comments whether or not to support __call__. I would definitely say yes, but I don't quite understand what you are doing with __getitem__. I assume that NamedProperties in COM can have more than one optional argument, and if this os so, then calling would be the only way to pass more than one argument. From what I can see, at the moment we're supposed to do something like bla.accName[0] rather than bla.accName(0)? Also, what happens if you want to not provide the optional argument at all? Obviously in python you can't write bla.accName[], but with __call__ you could at least do bla.accName() Perhaps I don't quite follow what your __getitem__ etc is doing. Would you be able to provide me with an explination on this? Thanks again Mick On 25/10/2008 5:09 AM, Thomas Heller wrote: > 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). > ------------------------------------------------------------------------- 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
