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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-25 05:08:21

>>>I am very interested in this and would like very much to see how you
>>>will do this at design time. In particular I am interested in how
>>>event handlers can be set at design time. All without C++ reflection
>>>of course and using strictly the C++ standard, since you are
>>>confident that this can be done. My
>>>      
>>>
>>You can emulate "design time". This is what both C++ Builder/ .Net do.
>>You set an event at design time, but behind the scenes, a new event
>>handler is created.
>>    
>>
>
>That is true, but there is the ability to create properties and event
>handlers before the program is running in a visual design time environment.
>That is why I believe one needs reflection in C++ in order to do this. While
>you are right that the design time environment is able to write code in
>files in order to create the handler, which the programmer will then fill in
>himself with whatever functionality he chooses, there is more to it. The
>  
>
Yup, you are right. Here's what I'll do (of course, in about 3-4 months :D)
At run-time, you can register your own "design-time properties" (in 
addition to the predefined ones). So, all you need to do, in order  for 
your properties to be known to the UI designer, is to run your program 
once. That's it!

>design time environment must also hook the event handler to the event when
>the objects encapsulating the event and the event handler are created at
>run-time. In C++ Builder this is done by actually writing strings to a
>  
>
that is not complicated. See how win32gui handles events now, and also, 
stay tuned for the CUJ November issue ;)

>resource file, which afterward gets read in at run-time and, through
>reflection implemented as an extension to C++, the event handler and the
>event source are hooked together. In .NET, whose inner workings I understand
>  
>
No need - again, see how win32gui handles events right now.

>I know much can be done through boilerplate code, so it is possible that all
>the code to do this could be done by a design-time environment which creates
>enough code to make this automatically work at run-time. But even in this
>  
>
No, no need for that. Besides, I hate boilerplate code - maintenance 
nightmare.

>>Now, you can easily set event handlers at compile time. It'll get even
>>better (look out for CUJ November issue ;)).
>>    
>>
>
>I understand this possibility and applaud your work, but it still is not
>design time programming ( yet ).
>
>  
>
I'll be - pretty soon ;)

>>>view of event handlers is that any "component" ( see below ) within
>>>such a system should be capable of handling any event generated by
>>>any other component; which is true of both C++ Builder and Managed
>>>C++/.NET.
>>>      
>>>
>>I don't think you'd want any component to catch events generated by
>>any other component.
>>What I think you'd like is: handle on a dialog, any notification
>>coming from its controls. If the dialog does not/cannot handle this
>>notification, propagate it up the chain (dialog's parent, grand
>>parent, etc.).
>>    
>>
>
>I heavily disagree with this model. That's MFC/OWL and I would guess plenty
>of other GUI environments, and it is old. There is no reason why any
>component shouldn't be able to hook events.
>
>  
>
Please explain "hook events".

>>This is how win32gui handles events right now.
>>
>>And I think this is how C++ Builder/.net handles events as well.
>>    
>>
>
>You are completely wrong on this last point. Any C++ Builder component can
>hook an event ( called a __closure ). Any .NET component can hook an event
>  
>
Do you mean "respond to an event"?

>( called a delegate ). I am not trying to put down what seems to be your
>excellent work in any way, but you are conceptually following a model for
>event generation/event handling which has been superceded IMHO. If you like
>that model, fine. But I want to point out to you that a much better model,
>and much more in the spirit of C++, is to allow any functor to handle an
>event. And of course boost::signal<> is built around this idea. If your
>events are multi-casting, which I am sure they must be, there is no reason
>putting limitations on who can handle them unless you are using a means of
>event generation which is in itself restrictive in what it can do. All you
>end up doing is making programmers who want to use your GUI angry that they
>must find workarounds for event handling for many cases for which you
>haven't yet conceived.
>
>  
>
I could really use some examples here ;) Because I really can't think of 
any. Maybe we are mis-reading eachother ;)

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)