Exporting events from Python COM class.

[Alex Martelli]

"Syver Enstad" <syver at NOSPAMcyberwatcher.com> wrote in message
news:ZYxO5.1229$cr6.17137 at news1.oke.nextra.no...
> It's easy to recieve events i Python, but what steps do you have to take
to
> export events from a python class and trigger them.

See win32com\demos\connect.py as an example.

Basically:

a. your server inherits win32com.server.connect.ConnectableServer
b. it ensures its _public_methods_ include all the _public_methods_
    of the just-named baseclass (important!)
c. it sets its classmember _connect_interfaces_ to the list of
    IIDs for the event (aka 'source') interfaces it wants to
    fire on
d. when it wants to 'fire' an event, the server instance calls
    upon itself the _BroadcastNotify method it inherits from
    said baseclass -- _BroadcastNotify takes as a first argument
    the boundmethod (or function) to call for each listener,
    as the second, the tuple of other args to be passed to
    said bound-method (or function)
e. the bound-method (or function) is invoked for each currently
    connected listener, its argument (possibly after 'self')
    being a reference to the listener (implementing the desired
    event, aka source, interface, of which at point c)
f. the eventmethod may be called on the listener, e.g., with
    .Invoke and a known dispatch-ID (this is what the demo does)

For points c and f I would prefer to write a little IDL (to be
compiled with MIDL) defining the dispatch-interface to be used
as source-interface for this task; this makes life easy for
clients which want to connect, and easier for us too at point
f, since we may call the eventmethod by-name, as usual.  MIDL.exe
can be downloaded as a part of Microsoft's free "Platform SDK",
unless you already have it around (e.g. as a part of Microsoft
Visual Studio).

Points e/f may be a little delicate in the very unusual case
in which you want your server to expose TWO source-interfaces --
you may need to check that the interface object that is being
passed to the notification-function implements the "right"
event-interface in each case.  But exposing >1 event itf's is
such a rare occurrence (and most clients would have trouble
connecting to any but the first/default one, anyway...) that
I don't think this is a problem at all.  Besides, failures
are explicitly handled (with a 'print' in the baseclass, but
you may override that to handle silently if you wish -- see
win32com\server\connect.py, the _OnNotifyFail method).


Alex