I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
Here is a general example of what I mean. I have a class which needs to respond to some event in your system. The event may be something which usually happens to a visual widget, but my class may neither be a widget as you define it, or it may be a widget but a non-visual one. In good old-fashioned Windows and MFC, only a visual widget ( read "window" or "control" ) can respond to the event. So you follow this paradigm and my poor class, or widget, if you will, despite the fact that it needs to respond to an event for whatever reason, can no longer do so without doing some exotic tricks. Why ? Because you have established some arbitrary barrier, something like "only a embedded widget, or another type of related widget window" can respond to the event. Of course there are no doubt tricks, such as have been used in Windows from time immemorial to get around such limitations, ie. creating a dummy window of the correct kind and doing god knows what other silly but necessary things. But why bother to create such a system with such limitations.
When I say respond to some event I almost always mean that my event handler ( or slot if you like that term ) will invariably just be notified that a particular event has occurred, and will do something accordingly within itself. Yes, I understand that many events have responses which change the nature of the visual actions drastically, and that you may feel that you do not want to allow certain classes/widgets to do so, but there is still no reason for such a limitation even in this case. C++ was created to give the programmer maximum control and maximum responsibility. You should honor that design. If the user of your GUI library wants to shoot himself in the foot by having some weird class handle an event in a way that does something really idiotic, let him. Putting up barriers such as, "I think that only X,Y, and Z class member functions should be able to handle this event" is nonsensical. With boost::signal<> allow any class to handle an event. If you want to maintain control internally you can use boost::signal<> easily enough so that your handler is the first to handle an event and can short-circuit everyone else. But don't limit what can handle events or not to the outside user.
Now I see your point. I still think there are rare cases for this ;) Yes, win32gui will allow it. As I think about it now - from December CUJ issue ;) You can bind an event handler to any window in your hierarchy of windows. I wanted to add this feature in the beginning, but then changed my mind. Anyway, it'll be there ;) Best, John -- John Torjo Freelancer -- john@torjo.com 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)