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
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 Freelancer -- john_at_[hidden] Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk