Handling Com Events in Python (was Python and Windows Scripting Host)

Mark Hammond MarkH at ActiveState.com
Thu Aug 10 20:29:55 EDT 2000


[Syver]
> > > Hmm, yes, but that mixes up the object you're automating with
the
> > > one that's receiving/handling its events.  I find that somewhat
> > > unpleasant/untrivial.

I agree, but had a hard time thinking of something better.

Presumably, whenever you respond to events, you also need to control
the application in some way.  There is almost always some state that
needs to be maintained between the app and its event handlers.

I saw 3 discrete choices:
1) VB model, with "Object_Event" name methods, global to the module.
No classes for the events at all.
2) Discrete objects for the event, and for the object itself.
3) Same object for the event and the object.

1) just sucks, IMO.  2) sounds appealing, but makes it very hard to
communicate state between the 2 objects.  I feared that the reality
was that in 100% of cases, each object would have a reference to the
other, meaning a nasty circular reference.

So I went with 3.

Note that events are still marked experimental, mainly as I am not
happy with them.  Also note that "DispatchWithEvents" is really just
an event helper, and isnt that many lines of code - power users are
free to handle events in any way they like.

[Alex]
> complex, aka non-trivial, I think; here, in particular, we're mixing
> two things which, while related, have conceptually distinct
> identities.  Nothing too terrible, I guess (and I don't have a
better
> architecture to propose, really; I ended up implementing something
> rather similar when I COM-enabled a proprietary scripting language
> that we develop and distribute with our applications -- although
> there are, I think, a few worthwhile enhancements which could be
> taken from that architecture and applied to Python's win32com,
> it's really minor issues).

Agreed completely.  Your ideas would be most welcome.

Mark.






More information about the Python-list mailing list