[ctypes-users] ctypes state of development

[Thomas H. <th...@py...>]

Maybe nobody has noticed, but I made good progress with the further
ctypes development. All the following developments are in the main trunk
and are ongoing work.

The 'stable' ctypes version is in the CVS branch 'branch_0_4'.

Functions
=========

I 'merged' the DynFunction type (which is used to call DLL functions)
and the CFunction type (used to create callback functions) together into
a single CFuncPtr type.  This is a 'first class' ctypes' type, you can
store in or get it from Structure/Union fields, you can call it, you can
pass it as a parameter to functions, you can use it as a function result
type, use it in a function prototype, and so on.  The advantage is that
there's nothing too special any more with this type (compared to other
ctypes types), so the code size actually has decreased a bit.  All in
all, it is IMO much more consistent.

The recommended way to create callback functions has changed: you no
longer subclass CFuncPtr directly, there are factory functions which
create CFuncPointer subclasses.

So, instead of writing

class WNDPROC(CFuncPtr):
    _argtype_ = (c_int, c_int, c_int, c_int)
    _restype_ = c_int
    _flags_ = FUNCFLAG_STDCALL

now it should read this way:

WNDPROC = STDAPI(c_int, c_int, c_int, c_int, c_int)

Similar to STDAPI there's a CALLBACK function creating __cdecl callback
functions.

The STDAPI and CALLBACK factory functions expect the result type as the
first parameter, and the argument types as the remaining parameters.
They return a new CFuncPtr subclass.

I'm not really happy with the names of these functions, and I wonder if
it would be better to change the signature in one of these ways:

  STDAPI(restype, argtypes_tuple)
or
  STDAPI(restype, functiontype_name, argtype_tuple)

which would the make the above example

  WNDPROC = STDAPI(c_int, (c_int, c_int, c_int, c_int))
or even
  WNDPROC = STDAPI(c_int, "WNDPROC", c_int, c_int, c_int, c_int)

(It may be usefull, at least for debugging, to specify the name of the
class to be created).


Accessing functions in dlls has not changed:
  windll.user32.GetModuleHandleA


Structures
==========

Specifying field types with format characters like "i" or "b" is
deprecated, but since there are probably a lot of structure definitions
written already with them I will probably change the code so that they
are still accepted (with a deprecationwarning triggered).  Unfortunately
backwards compatibility for CFunction subclasses will not be provided,
usually there are only a few places in the code you will have to change.


COM support
===========

I have already started with the COM stuff again.  Currently the COM
interface for IOleWindow for examples has to be implemented with code
like this:

class IOleWindow(IUnknown):
    _iid_ = GUID("{00000114-0000-0000-C000-000000000046}")
    _methods_ = [
        STDMETHOD(HRESULT, "GetWindow", POINTER(c_int)),
        STDMETHOD(HRESULT, "ContextSensitiveHelp", c_int)]

class IOleWindowPointer(COMPointer):
    _interface_ = IOleWindow

IMO, this looks nice.  What do the COM experts on this list say?

Thanks for the attention,

Thomas