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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-26 10:31:03

>>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_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)