Torbjorn Tyridal schrieb:
> On Tue, Oct 28, 2008 at 4:23 PM, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>> I'm using comtypes (0.5.2) with the DSF
>>> (http://www.microsoft.com/whdc/devtools/DSF.mspx), and it seems to me
>>> that the generated prototypes for methods requiring object pointers
>>> are wrong.
> 
>> What is ISoftUSBString in the IDL (I assume a COM interface) and what is
>> SoftUSRString in the IDL (I assume a coclass)?
> 
> Good questions, it seems like microsoft is not distributing the idl,
> only tlb and dll files.

Note: You can decompile the binary typeinformation in tlb, dll, and exe files
with MS oleview program back into IDL.

> However I have the same problem with DSF.HotPlug not accepting
> DSFDevice objects. And for DSF the idl is available:
> 
> interface IDSF : IDispatch
> {
> ...
>     HRESULT _stdcall HotPlug ([in] DSFDevice *pDSFDevice,
>                               [in] BSTR       bstrBus,
>                               [out, retval] IDSFBus **ppiDSFBus);
> ...
> };
> 
> interface IDSFDevice : IDispatch
> {
> ...
> };
> 
> coclass DSFDevice
> {
>     [default] interface IDSFDevice;
>     [default, source] interface IDSFDeviceEvents;
> };
> 
> 
> again,
> import comtypes.client as cc
> 
> dsf = cc.CreateObject("DSF.DSF")
> mydev = cc.CreateObject("DSF.DSFDevice")
> 
> dsf.HotPlug(mydev, "USB2.0") # throws TypeError
> 
> 
> comtypes generated code:
> IDSF._methods_ = [
> ...
>     COMMETHOD([dispid(1248), helpstring(u'Plugs the given DSFDevice
> into the bus which is defined eithe by its GUID or friendly name.')],
> HRESULT, 'HotPlug',
>               ( ['in'], POINTER(DSFDevice), 'pDSFDevice' ),
>               ( ['in'], BSTR, 'bstrBus' ),
>               ( ['retval', 'out'], POINTER(POINTER(IDSFBus)), 'ppiDSFBus' )),
> ]
> 
> changing that ( ['in'], POINTER(DSFDevice) to ( ['in'],
> POINTER(IDSFDevice) solves the problem
> 

I think that the code generation should not be changed; instead I would prefer
to extend the CoClass class (which is the base class for DSFDevice in your case)
so that it accepts interface pointers to the CoClass' default interface in
method calls when the argument type is POINTER(CoClass-subclass).  The following
patch should do this, can you please try it out?

Index: comtypes/_meta.py
===================================================================
--- comtypes/_meta.py   (revision 428)
+++ comtypes/_meta.py   (working copy)
@@ -14,6 +14,11 @@
     result.__dict__["__clsid"] = str(self._reg_clsid_)
     return result
 
+def _coclass_from_param(cls, obj):
+    if isinstance(obj, (cls._com_interfaces_[0], cls)):
+        return obj
+    raise TypeError(obj)
+
 #
 # The mro() of a POINTER(App) type, where class App is a subclass of CoClass:
 #
@@ -42,8 +47,10 @@
             clsid = namespace["_reg_clsid_"]
             comtypes.com_coclass_registry[str(clsid)] = klass
         PTR = _coclass_pointer_meta("POINTER(%s)" % klass.__name__,
-                                  (klass, c_void_p),
-                                  {"__ctypes_from_outparam__": _wrap_coclass})
+                                    (klass, c_void_p),
+                                    {"__ctypes_from_outparam__": _wrap_coclass,
+                                     "from_param": 
classmethod(_coclass_from_param),
+                                     })
         from ctypes import _pointer_type_cache
         _pointer_type_cache[klass] = PTR
 


-- 
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

Reply via email to