Exporting events from Python COM class.

[Toby Dickenson]

Mark Hammond <MarkH at ActiveState.com> wrote:

>> I also think there's a bug in win32com\server\connect.py's
>> Advise implementation....

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

I agree

>Indeed, way back when this sample was written, there was a C++ "connect" 
>ATL sample.  This "connect" sample was such an interface - it did not 
>support IDispatch.  Much of this code was tested against that component.

This has come up before... last time I asserted that such a C++ event
sink was broken, since all event sink interface are supposed to be
'dispinterface' (that is, methods are called always using Invoke)

Mark challenged me to find some documentation backup up that
assertion, but I couldnt find any ;-(


>As I mentioned, I am not 100% sure of the COM semantics here.  At the 
>time, I could not find documentation to imply that COM QI rules could be 
>violated for events - thus, doing a QI for a specific interface is 
>expected to return that interface, and not IDispatch.

This comes down to the difference between IDispatch and IID_IDispatch.
Its perfectly ok for an object to have two different interfaces that
are both IDispatch - they just need a different IID.


>Hence we have the second QI for specifically IDispatch.

The second QI actually asks for IID_IDispatch, which gives one of
possibly many different IDispatch interfaces.


Toby Dickenson
tdickenson at geminidataloggers.com