I like multicast events in Microsoft .NET. Basically, a single event property (using Delphi terms) can be linked to multiple event handlers (as opposed to standard Delphi's events which can only be linked to a single event handler at most). In Delphi 7, a multicast technique is already used internally in TApplicationEvents, AppEvnts unit. In this case, the result is that you can have multiple TApplicationEvents components in your project (perhaps on different forms), each of which can receive and handle events coming from the global Application component.
It seems that some research is being done of multicast events support for future versions of Delphi for Win32.
In one of my projects, I've been experimenting with my own implementation (just for my own, non-visual classes, without any designtime support). It seems to be a success and I believe it helped me write cleaner, more modularized code. Writing it was fun, too.
3 comments:
Personally I'm a bit hesitant about multicast events. I'm yet to use them in a proper project but I don't like the idea of what would be a single easy to follow unicast event handler being changed into multiple handlers with unpredictable quasi-thread-like behaviour. Sounds like a recipe for future hair pulling debugging sessions and a more difficult flow of execution for others to follow when reading the code.
I'll give them another look at some point in the future but I think you'd need to be careful not to go overboard with them.
Thanks for your comment! In my opinion, multicast events don't make debugging much more complicated: the main difference is that the source object holds a list of method pointers instead of a direct link; when the time comes to fire an event, it will simply iterate the list and call each target handler.
I'm fairly certain the multicast event handlers in .NET are called in an indeterminate order which is one of the main reasons I find them unattractive.
Post a Comment