Exporting events from Python COM class.

[Alex Martelli]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:8ueb9l01voj at news1.newsguy.com...
    [snip]
> c. it sets its classmember _connect_interfaces_ to the list of
>     IIDs for the event (aka 'source') interfaces it wants to
    [snip]
> Points e/f may be a little delicate in the very unusual case
> in which you want your server to expose TWO source-interfaces --

Oops -- I just checked win32com\server\connect.py, and this
just won't fly -- the client-object trying to connect is
always queried for the *first* interface in the list, so
the others (if any) seem to be there just to cause confusion
(when the client does the FindConnectionPoint for an IID
that's in the list, but not the first one, it will appear
to succeed -- but then the call to Advise will fail!).

A good thing that needing to use >1 source interface is
so rare.  I think ConnectableServer should be modified
to accept *just one* "_connect_interface_" in the Python
class that inherits from it, not a list... the fact that
it's a list is (it seems to me) misleading.  (I fully
understand that supporting separate connectionpoints
for more than 1 source-interface, such a rare need, is
an unwarranted amount of effort!-).

I also think there's a bug in win32com\server\connect.py's
Advise implementation -- if a client tries to connect (to
the one-and-only source interface), with an object that
also implements some _other_ dispatch-interface (and
returns that 'other' when QI's for IDispatch), the methods
being called when events are fired are going to be methods
on the _default_ IDispatch version of the client-object,
NOT on the specific dispinterface it asked to connect.  I
think this violates COM's rules, and, while it's unlikely
that a specific client implementation will trigger this
bug, I expect _very_ subtle, hard to reproduce, hard to
understand, little semantics disasters if/when it happens.

Is the second call to QueryInterface on that Advise method
really necessary...?  I guess so, since commenting it out
makes win32com.demos.connect.test() fail with an AttributeError
on Invoke, but I don't really understand why... (would it
work OK if the source-interface were to inherit IDispatch
as it should and the event-generating Python COM server
was properly apprised of that...?)


Alex