From: John Torjo <john.lists@torjo.com>
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.
I'm not Boost.Signal expert, but I think that is possible. You need to group your slots so that you can impose an order. Thus, the enabler would be in the group that sorts first. Then, your signal should be defined with a Combiner that won't call further signals if any returns false. That means that your enabler will always be called first and, if it returns true, the rest of the slots will be invoked. HTH -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;