Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-23 03:02:45

> 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


John Torjo
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- v1.3beta released - check out splitter/simple_viewer,
    a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- (logging           - C++)
--         (viewing/filtering - Win32)
--        (debugging         - Win32)

Boost list run by bdawes at, gregod at, cpdaniel at, john at