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.
Your analysis and your proposed solution looks ok to me.
However, here are some random thoughts about the dyndispatch branch:
1. I consider the 'dynamic=True' keyword (and your 'dynamic' instance
variable a temporary solution. Eventually they should become
unneccessary, and comtypes would decide itself what to use. The
primary problem, IIRC, is to avoid the expensive code generation
step. Another problem is that, for unknown reasons, using the
IDispatch interface is probably more robust than using the custom
interface, as we have seen by several posts on this list.
2. Code using IDispatch should probably use separate classes,
depending on whether type information is available for the interface
(where we can use ITypeComp.Bind() or something like that) or not
(where we have to use GetIDsOfNames()).
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!).
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. Since IDispatch calls do not need
type information for the method return values, arguments, and
properties saves a lot of time. In principle, code similar to this
snippet will be generated:
class MyCOMObject(_Dispatch):
"docstring"
@property
def Count(self):
return self._invoke_propget(42)
@property
def _NewEnum(self):
return self._invoke_propget(-4)
def doit(self, Arg):
"docstring"
return self._invoke_method(3, Arg)
Whether the generated code will be cached in the module at runtime
only, or into modules in the filesystem, can be resolved later.
--
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
