Exporting events from Python COM class.

[Mark Hammond]

Alex Martelli wrote:

>> Thus, I _think_ you could get the behaviour you want by changing the "1"
>> to IID_IDispatch, and removing the second QI.
> 
> 
> Yes!  It works fine.  It suffices to substitute lines 33-34
> in win32com.server.connect.py with the single line
> 
>    interface =
> pUnk.QueryInterface(self._connect_interfaces_[0],pythoncom.IID_IDispatch)
> 
> and that now appears to work flawlessly.

OK - I have made that change.

>>> Some COM background (which I'm sure you don't need, but may come
>>> in handy for some readers!):
>> 
>> Thanks - and to my mind, is exactly the reason why I _dont_ want to
>> break the rules here!
> 
> 
> But you do, if you QI a dispinterface for IID_IDispatch.

Yes - Toby and your explanations have cleared this up for me - thanks!

>> So really, they are saying there _is_ good reason to do this, but it is
>> not compatible with VB.
> 
> *sigh* not really, although I see how you could read it this
> way.  There is NO good reason to have a source-interface be
> dual.  If VB (and, actually, every other scripting language)
> were of no importance, you could make it custom (that's OK,
> you can do it now, as long as you know no scripting language
> nor VB will be able to sink those events -- as long as you're
> at it, why follow the connection-point protocol either -- you
> can optimize connection/disconnection operations too, by
> customizing them to your actual needs; connection-point is
> designed with generic applicability in mind, basically to
> enable connection from scripting and VB...).  If VB and other

> scripting languages matter, you clearly have to make it a
> dispinterface (that's what they know how to sink, of course).

I see where you are coming from, but don't take your point.  I don't see 
why the IDispatch-like mechanism buys genericity.  It buys simplicity of 
implementation.  If the event interfaces are described in a type library 
and VB is capable of putting together arbitrary vtables given the tlb 
definition, I don't see why the IDispatch like mechaism is central to 
the scheme.

And if is not central, the cost (dispid lookup, VARIANT conversion, etc) 
may be worth reducing in some apps - especially if they know a vtable 
capable client _may_ possibly connect, and wish to support high 
performance when they do.

Anyway, it isn't directly relevant to win32com.

 > (I gather the .NET "solution" to "how do I script just
 > ANY interface" is yet another, i.e., that the _interpreter_
 > has to take the burden [using the rich metadata supplied,
 > and with some modest assist from the runtime] since there
 > is no real "broker" layer as in Corba -- but you know a
 > zillion more times than I do on .NET, so maybe you can
 > confirm or deny this impression!-).

If I understand the question, you are correct.  An interpreter running 
in the .NET environment could get all the meta data it needs at runtime, 
and package a Reflection call at runtime.  It is actually quite trivial.

However, I am not sure _why_ you would do this.  Part of the advantage 
of .NET is running your language under their VM, so then this becomes a 
compiler issue.

If you want to use good-old, interpreted CPython, just use the .NET COM 
interop layers - they have already dont the .NET integration, and lots 
of tools already support COM.

In terms of win32com, .NET objects just looks like COM objects with 
complete, rich type information - so no current need for specific .NET 
extensions to CPython.  Some _will_ popup, no doubt (and the 
"bForDemand" changes to makepy were basically done for it ;-)

 > (Where does one submit win32all patches, and in what diff
 > format...?  The only diff programs I have easily available
 > on Windows are GUI-oriented, but I can of course download
 > whatever is required, just point...!-).

Just to me in whatever format is easiest.  If you did a CVS fetch just 
before mailing, then the entire file is fine.  If it happens too 
regularly I will get sick of it and just give you CVS commit access ;-)

Mark.