|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-08 09:42:05
On Monday 08 March 2004 03:39 am, E. Gladyshev wrote:
> I am trying to use boost::signals in my GUI project.
> The capturing feature is needed when
> a window has many separate regions (each region is a slot)
> and a region wants to capture all mouse events after the mouse enters
> this region. It is a very typical situation.
Ah, interesting. Now that I think about it, yes you can do this... see at the
end.
> The ability to enumerate slots in a defined order is
> necessary for building something similar to callback chains.
[reodered]
> It seems to me that we need a finer control over the slots.
I agree. There was a great proposal here to define the ordering, but it's not
implemented yet :(
http://article.gmane.org/gmane.comp.lib.boost.devel/25152/
> For instance, in Win32 you can insert your window callback
> function into the existing chain.
>
> Something like
>
> callback prev_cb;
>
> void my_callback()
> {
> if( some condition )
> {
> prev_cb(); //propagate the signal futher
> do_something1();
> }
> else
> {
> do_something2();
> return; //stop signal propagation
> }
> }
>
> main()
> {
> window w;
>
> prev_cb = register_callback(w, my_callback)
> }
>
> I am not sure what's the best way to implement something like this with
> boost::signals.
The ordering is a problem. The only way to guarantee an ordering is to use
groups (which is not always feasible).
However, the other part (including capturing) can be handled by groups and
combiners. Use the "until_true" combiner I posted previously, and have your
slot return "true" to stop propagating the signal.
As for the capturing, you can use groups:
const int capture = -100000; // big negative number
{
boost::signals::scoped_connected captured =
sig.connect(capture, slot_to_capture);
// slot_to_capture always executes first, so it gets all the events.
} // end of scope, slot_to_capture disappears
If slots had a well-defined order, everything would be peachy.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk