From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-25 10:54:37
From: John Torjo <john.lists_at_[hidden]>
> >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.
> Fine with me. However, what I want is to halt processing from any event
> handler. So, if I have 10 event handlers for an event, and handler 5
> says stop, I won't call the rest.
The same solution applies.
> While that may or may not be possible with a boost::signal, I would
> prefer a simple (ordered) array of functions to call.
Suit yourself. I was just pointing out that what you wanted was,
indeed, possible with Boost.Signals and that you didn't need to
reinvent it. Perhaps what you want could be implemented as an
adjunct to Boost.Signals? That is, it could be another way to
manage signals and slots that joins, rather than replaces, what
exists. (It may also be possible to use a policy to control how
the dispatching occurs such that the ordering you want is imposed
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk