The problem with the "registering your self in a slot" approach, is that most events generate actions -> ie they application flow is bi-directional. The signal/slot approach (usually) suffers from not being able to send a response back to the event sender.
I think there's a bigger problem here - with boost::signal. When handling some events, in a certain handler - you might find yourself wanting to turn off further processing of events. Imagine this case: You might want to turn off commands (like, "File Save", "Undo", "Redo", etc.) which come from accelerators (key-stokes). In such a case, you'd like to register your event handler to handle commands first. Then, see if a command is enabled. If so, allow other handlers to handle it. If it's disabled, turn off further handling. Correct me if I'm wrong, but I don't think that's possible with boost::signal. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)