Re: [boost] Re: Re: Java style GUI in C++

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-23 16:27:31

From: John Torjo <john.lists_at_[hidden]>
> > 
> > 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;