Hi all - Looking at fixing a problem with events, I'm realizing that my original plan has a big hole in it :( Here's the situation: the framework requires that an event be implemented by providing an add_SomeEvent and a remove_SomeEvent method. However, the actual storage and mechanisms used to call the delegates registered via those special methods are completely up to the implementor of a class. When you write, for example, a class with an event in C# using the MS tools, you get: - add_* and remove_* methods - a private internal field to hold the delegate You do *not* get an automagic method to fire the event, because the class implementor is supposed to provide this if it appropriate (but may choose not to). The current Python.NET event stuff expects this setup, and it allows you to treat the event as a callable object - when you call the event, it tries to call that internal delegate. The problem is that its wrong :) According to everything I can find, a class is supposed to provide an 'OnSomeEvent' method to fire an event if it is appropriate for client code to fire the events of the class explicitly. If a class does not provide an 'OnSomeEvent' method, then it is assumed that it is not appropriate for the event to be fired by a client (and there is in fact no reliable way for the client to even try, since the dispatching to subscribers is purely internal to the class and could be done in arbitrary ways). I'm tempted to remove the ability to call event objects directly from Python, as this would match the convention and what you'd have to do in C# or VB, etc. (you'd call the OnSomeEvent method instead). The alternative would have to be doing some kind of automagical thing where we'd try lookup up an OnXXX if the usual private event field wasn't there, but that seems nasty... thoughts? Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com