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

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-08-22 19:19:13

Mathew Robertson wrote:
> [This assumes I understand what you are refering to with the term
> "design time"...]

By design time I mean an environment which occurs before the module is
executed within a process on an OS, during which one can set properties and
events ( event handlers ) for "components". The "components" are then
usually created automatically at run-time, their properties are set to
values and their events are hooked to event handlers in other "components"
which are usually automatically created at run-time. Ideally one should be
able to create components, and set properties and event handlers for
components at run-time as well.

>
>>>> VC++ Managed C++ .NET is very nice but it is even further away from
>>>> standard C++. In neither do you have to write hundreds of lines of
>>>> code to do any GUI programming of significance. In order to have a
>>>> really top-rate C++ GUI library I believe one needs reflection in
>>>> C++ in order to do the sort of
>>>
>>> Not true. It would be great if you had reflection, but it's not a
>>> necessity.
>>>
>>> I'll show you (in about 3-4 months) that you don't need reflection
>>> to set GUI properties at design time. It'll be just like VB, but
>>> only better ;)
>>
>> 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 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.
>
> This can be handled by the FOX library _now_.  If a widget is capable
> of handling the incoming event, then it does handle it, otherwise the
> event just propogates its way back up with widget tree, or it doesn't
> get handled.
>
> It works because it uses message maps which are statically defined
> (-> they are a design time constraint) -> no need for reflection -
> either the widget has a handler for the event in its message map, or
> it doesn't.

I will take a look at it, but message maps do not ring a positive bell with
me. Nonetheless my mind is open.