Torbjorn Tyridal schrieb:
> Hi, I have another one for you:
>
> from the idl file (oleview)
>
> interface ISoftUSBEndpointEvents : IUnknown {
>
> ...
>
> [helpstring("Fired when an IN transaction is received from the host.
> Allows device simulator to directly return data to host controller for
> the transaction."), helpcontext(0x000006bd)] HRESULT _stdcall
> OnReadTransfer(
>
> [in] unsigned char DataToggle,
>
> [out] unsigned char* pbDataBuffer,
>
> [in] unsigned long cbDataBuffer,
>
> [out] unsigned long* cbDataWritten,
>
> [out] unsigned char* pbStatus);
>
>
>
> Note the "[out] unsigned char* pbDataBuffer," while we compare this to
> microsoft documentation for ISoftUSBEndpointEvents::OnReadTransfer,
> and especially the given example
> (http://msdn.microsoft.com/en-us/library/bb201520.aspx)
>
> STDMETHODIMP CSoftUSBEndpointEvent::OnReadTransfer(__in BYTE DataToggle,
> __in_bcount(cbDataBuffer) BYTE *pbDataBuffer,
> __in ULONG cbDataBuffer,
> __out ULONG *cbDataWritten,
> __out BYTE *pbStatus)
>
>
> That [out] has now become an __in because the caller allocates the buffer.
As far as I understand this, '__in_bcount(cbDataBuffer) BYTE *pdDataBuffer' is
MS' SAL (source code annotation language). It means that the caller has to
supply
a buffer of 'cdDataBuffer' length, the callee will fill it, and the contents
will be returned (that is the 'out' value then).
There is a somewhat similar notation in the IDL files for COM (size_is,
length_is, and so on),
but type libraries have no way to represent this information. The MIDL
compiler, when it
compiles an IDL file uses this info to generate marshalling C/C++ code that can
be
used to create proxy dlls for COM object.
However, comtypes has no way to use this annotation simply because it is not in
the
typelib, as I said before.
> is there something (else than editing the generated file) I can do to
> solve this?
>
Are you calling this method, or are you implementing it with comtypes?
(Since it is an event interface, I assume the latter.)
If *calling* this method, you should not call the obj.OnReadTransfer(...)
method,
instead you should call the low level obj.__com_OnReadTransfer(...) method which
is also created at runtime by comtypes' metaclasses. See, as one example, the
QueryInterface implementation in comtypes\__init__.py:
class IUnknown(object):
def QueryInterface(self, interface, iid=None):
"QueryInterface(interface) -> instance"
p = POINTER(interface)()
if iid is None:
iid = interface._iid_
self.__com_QueryInterface(byref(iid), byref(p))
clsid = self.__dict__.get('__clsid')
if clsid is not None:
p.__dict__['__clsid'] = clsid
return p
If you are *implementing* this method - is there a problem at all?
The caller HAS already allocated the buffer, you only have to fill it.
Anyway, if you have special requirements that can not be fullfilled by
the 'high level' method implementation then you should use the 'low level'
implementation; I have posted several times about them.
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
